[Mesa-dev] [PATCH] svga: fix git_sha1.h include path in Android.mk

[Rob Herring]

On Sun, May 28, 2017 at 1:31 PM, Mauro Rossi <issor.oruam at gmail.com> wrote:
>
>
> 2017-05-28 16:46 GMT+02:00 Rob Herring <robh at kernel.org>:
>>
>> On Fri, May 26, 2017 at 10:15 AM, Mauro Rossi <issor.oruam at gmail.com>
>> wrote:
>> > Fixes the following building error:
>> >
>> > external/mesa/src/gallium/drivers/svga/svga_screen.c:26:10:
>> > fatal error: 'git_sha1.h' file not found
>> >          ^
>> > 1 error generated.
>> > ---
>> >  src/gallium/drivers/svga/Android.mk | 4 +++-
>> >  1 file changed, 3 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/src/gallium/drivers/svga/Android.mk
>> > b/src/gallium/drivers/svga/Android.mk
>> > index c50743d509..d19bd59bfe 100644
>> > --- a/src/gallium/drivers/svga/Android.mk
>> > +++ b/src/gallium/drivers/svga/Android.mk
>> > @@ -30,7 +30,9 @@ include $(CLEAR_VARS)
>> >
>> >  LOCAL_SRC_FILES := $(C_SOURCES)
>> >
>> > -LOCAL_C_INCLUDES := $(LOCAL_PATH)/include
>> > +LOCAL_C_INCLUDES := \
>> > +       $(LOCAL_PATH)/include \
>> > +       $(call
>> > generated-sources-dir-for,STATIC_LIBRARIES,libmesa_dricore,,)/main
>>
>> Add this path to LOCAL_EXPORT_C_INCLUDE_DIRS in libmesa_dricore and
>> add libmesa_dricore as a static lib here instead.
>>
>> Rob
>
>
> Hi Rob,
> just a few questions,
>
> why should we export the header which is artificially associated to
> libmesa_dricore
> and why treat this as a 'fake dependency'? The LOCAL_C_INCLUDE should
> suffice
>
> What is benefit in doing this? What is the drawback in using the android
> macro created for this purpose?

I can think of several reasons:

LOCAL_* variables are more simple and less likely to change than
generated-sources-dir-for. Doesn't matter so much when there's only
one dependency, but if several drivers needed this, then it becomes
more important. Also, I don't know how to do the equivalent of
generated-sources-dir-for in blueprint files, but exporting includes
is easy.

It keeps any details of the structure of libmesa_dri_core within it.
For example, look at the mess libelf was with include paths changing.

There are now "header libraries" which would be more what we want here
as we don't need to link it. However, those are new and won't work in
prior android versions, but eventually we'll want to move to that.

Maybe the header should be it's own module if it's really not related
to the rest of libmesa_dri_core. The other option is create a variable
with the path in libmesa_dri_core and then use it here (in
LOCAL_C_INCLUDE). I think there's a few examples of doing that.

Rob