[Mesa-dev] [PATCH] Android: glsl: add rules to generate ir_expression*.h header files

[Mauro Rossi]

2016-09-02 11:50 GMT+02:00 Emil Velikov <emil.l.velikov at gmail.com>:
> On 2 September 2016 at 05:35, Tapani Pälli <tapani.palli at 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.