[PATCH] libdrm: intel/Android.mk: Filter libdrm_intel library requirements on x86/x86_64

[Emil Velikov]

On 14 March 2018 at 17:30, John Stultz <john.stultz at linaro.org> wrote:
> On Wed, Mar 14, 2018 at 10:21 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 14 March 2018 at 16:47, John Stultz <john.stultz at linaro.org> wrote:
>>> When building AOSP after updating libdrm project to the
>>> freedesktop/master branch, I've seen the following build errors:
>>>
>>> external/libdrm/intel/Android.mk: error: libdrm_intel
>>> (SHARED_LIBRARIES android-arm64) missing libpciaccess
>>> (SHARED_LIBRARIES android-arm64) You can set
>>> ALLOW_MISSING_DEPENDENCIES=true in your environment if this is
>>> intentional, but that may defer real problems until later in the
>>> build.
>>>
>>> Using ALLOW_MISSING_DEPENDENCIES=true when building allows
>>> things to function properly, but is not ideal.
>>>
>>> So basically, while I'm not including the libdrm_intel package
>>> into the build, just the fact that the Android.mk file references
>>> libpciaccess which isn't a repo included in AOSP causes the build
>>> failure.
>>>
>>> So it seems we need some sort of conditional filter in the
>>> Android.mk to skip over it if we're not building for intel.
>>>
>> Could swear I asked a few times already, but cannot see an answer.
>> Why/how does this happen - did you forget to set BOARD_GPU_DRIVERS?
>
> Again, this is from the Android build, as the top level Android.mk calls:
> include $(call all-makefiles-under,$(LOCAL_PATH))
>
> Which includes all Android.mk files in all the sub directories
> (regardless of any BOARD_GPU_DRIVERS value).
>
> The error is that while we don't build the libdrm_intel module, the
> android build system still throws a error when any
> LOCAL_SHARED_LIBRARIES files aren't present in the larger build
> environment.
>
So Android would evaluate dependencies, even when the object is not
build/required.
That is fairly counter intuitive, hence why I've been stuck in suck a loop.

Fwiw the patch is
Reviewed-by: Emil Velikov <emil.velikov at collabora.com>

Thanks for the explanation and patience!
Emil