2017-05-28 21:02 GMT+02:00 Rob Herring <r...@kernel.org>: > On Sun, May 28, 2017 at 1:31 PM, Mauro Rossi <issor.or...@gmail.com> > wrote: > > > > > > 2017-05-28 16:46 GMT+02:00 Rob Herring <r...@kernel.org>: > >> > >> On Fri, May 26, 2017 at 10:15 AM, Mauro Rossi <issor.or...@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 >
Thanks The generation rules for git_sha1.h are now in src/mesa/Android.gen.mk which is included by two android makefiles hereby reported in their order: src/mesa/Android.libmesa_dricore.mk src/mesa/Android.libmesa_st_mesa.mk Which is better to use to do the LOCAL_EXPORT_C_INCLUDE_DIRS or is it the same? M.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
