2016-09-02 11:50 GMT+02:00 Emil Velikov <emil.l.veli...@gmail.com>: > On 2 September 2016 at 05:35, Tapani Pälli <tapani.pa...@intel.com> wrote: >> Hi; >> >> Thanks, I was trying to work on the same issue but did not quite get it >> working .. will test this one with N build. >> >> FYI this patch contains both of these (which I believe were issues already >> before mentioned changes, just somehow revealed only with N build?): >> > The issue is makefile order/parallel jobs related. > > IIRC latest builds use intermediate tools to convert the makefiles, > thus they could easily reshuffle the former or make the latter easier > to hit.
I've also notice that android 7.0 build system is more unforgiving and some build errors appear just in x86 32bit builds > >> https://patchwork.freedesktop.org/patch/107759/ >> https://patchwork.freedesktop.org/patch/106788/ >> > Was going to ask the question that Rob covered in his summary - why > don't we opt for the 'Android way' of pulling dependencies (generated > files and/or includes) by referencing the respective static/shared > lib. > >> >> >> On 09/01/2016 10:06 PM, Rob Herring wrote: >>> >>> Recent changes to generate ir_expression*.h header files broke Android >>> builds. This adds the generation rules. This change is complicated due to >>> creating a circular dependency between libmesa_glsl, libmesa_nir, and >>> libmesa_compiler. Normally, we add static libraries so that include paths >>> are added even if there's no linking dependency. That is the case here. >>> Instead, we explicitly add the include path using $(MESA_GEN_GLSL_H) to >>> libmesa_compiler. This in turn requires shuffling the order of make >>> includes. It also uncovered missing dependency tracking of glsl_parser.h. >>> > Looking at this and the inherent over-linking that one gets when > referencing shared libraries makes me wonder if those were things > considered by the Android build system engineers. > /me bites his tongue not to prevent ranting on the topic. Hi, in principle the macro local-generated-sources-dir-for would cover any case were in automake we have include like -I$(top_builddir)/src/compiler/glsl\ In this case -I$(top_builddir)/src/compiler/glsl\ would become: LOCAL_C_INCLUDES := \ $(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_glsl,,)/glsl but I've also seen that defining LOCAL_GENERATED_SOURCES to reach for other modules generated sources works ok > Have you seen/heard anything on the topic of deprecating the old > Android.mk files and/or a tool to assist/automate the conversion ? I've just seen this "improvement on the way", but I hope Android 7.0 will continue to allow using kati /Android.mk [1] https://news.ycombinator.com/item?id=10509843 [2] https://groups.google.com/forum/#!topic/ninja-build/YPby3GRBqHA [3] https://android.googlesource.com/platform/build/soong/ "Convert Android.mk files Soong includes a tool perform a first pass at converting Android.mk files to Android.bp files: androidmk Android.mk > Android.bp The tool converts variables, modules, comments, and some conditionals, but any custom Makefile rules or complex conditionals must be converted by hand." Yeah-rrrrggg! :-( New scripting language, at least for me, still to check what would be the threshold for defining 'custom' and 'complex', which would require handwritten parts in Android.bp files M. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
