[Mesa-dev] [PATCH v2 2/5] intel: Move tools/decoder.[ch] to common/gen_decoder.[ch].

[Rob Clark]

On Thu, Mar 23, 2017 at 6:32 PM, Matt Turner <mattst88 at gmail.com> wrote:
> On Wed, Mar 22, 2017 at 12:53 PM, Rob Herring <robh at kernel.org> wrote:
>> On Wed, Mar 22, 2017 at 6:50 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>> n 21 March 2017 at 20:58, Kenneth Graunke <kenneth at whitecape.org> wrote:
>>>> On Tuesday, March 21, 2017 4:40:26 AM PDT Emil Velikov wrote:
>>>>> On 21 March 2017 at 11:14, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>>>> > On 20 March 2017 at 22:04, Kenneth Graunke <kenneth at whitecape.org> wrote:
>>>>> >> This way they become part of libintel_common.la so I can use them in
>>>>> >> the i965 driver.
>>>>> >> ---
>>>>> >>  src/intel/Makefile.sources                          | 2 ++
>>>>> >>  src/intel/Makefile.tools.am                         | 2 --
>>>>> >>  src/intel/{tools/decoder.c => common/gen_decoder.c} | 2 +-
>>>>> >>  src/intel/{tools/decoder.h => common/gen_decoder.h} | 6 +++---
>>>>> >>  src/intel/tools/aubinator.c                         | 2 +-
>>>>> >>  5 files changed, 7 insertions(+), 7 deletions(-)
>>>>> >>  rename src/intel/{tools/decoder.c => common/gen_decoder.c} (99%)
>>>>> >>  rename src/intel/{tools/decoder.h => common/gen_decoder.h} (98%)
>>>>> >>
>>>>> >> I'd forgotten than I still had my gross symlinking hack in the first
>>>>> >> version of this series.  Here's a new spin which does this "properly" :)
>>>>> >>
>>>>> > You can do the symlink if you want to - I don't mind. This approach
>>>>> > will "bloat" every binary that links with libintel_common, since we
>>>>> > don't ask the linker to garbage collect.
>>>>> > Admittedly we only care about the ANV case, so I'll just follow-up and
>>>>> > add the GC toggle ;-)
>>>>> >
>>>>> Scratch that we do enabled it for ANV ;-)
>>>>>
>>>>> You really nicely reworked [in 3/5] making the code "debug only", so
>>>>> perhaps can we guard the code in gen_decoder.c the same way ? ... But
>>>>> that may interact badly with aubinator :-\
>>>>> Another option would be to guard the code in ifndef ANDROID - like toggle.
>>>>>
>>>>> Otherwise one will need to copy the _xml.h rules in Android, alongside
>>>>> a dummy libmesa_genxml-like library. The latter of which will need to
>>>>> be added as LOCAL_WHOLE_STATIC_LIBRARIES [for libmesa_intel_common] to
>>>>> pull/generate the headers. At the same time none of it is used since
>>>>> Android never defines DEBUG ... nor does it use the linker garbage
>>>>> collector (GC_SECTIONS)
>>>>> Tapani feel free to grep mesa for GC_SECTIONS and use in Android.
>>>>
>>>> Ugh, good point - I forgot about Android (and SCons, but thankfully we
>>>> don't care about SCons here).  I don't have any clue how to test Android
>>>> builds, so I'm going to go ahead and land it as is (sorry!).
>>>>
>>> No need to apologise - I'm not expecting !Android people to have the
>>> setup and/or do Android builds.
>>
>> Could we at least expect the !Android people to not commit things that
>> are known to break Android until the issue is solved?
>>
>> I can't keep up with the breakage on Intel, so I guess I'll stop caring.
>
> Is it easier for you to fix things before they're in the tree, vs after?
>
> We've got Jenkins doing a scons build to make sure that keeps working,
> but I'm not sure if it's reasonably possible to do the same for
> Android.
>
> Is your suggestion for Mesa developers to gate their patches on
> updating the Android build system?

to be fair, I guess not *every* patch is touching the build system..

That said, I guess intel has folks actually focusing on doing android
(judging by drm-hwc gerrit) so I guess in the intel case, Rob ignoring
it and different intel folks fixing the android build on their own
schedule seems like a valid option..

(although if somehow meson provided some magic way that more could be
shared between android and linux build systems, that would certainly
be a good thing.. building android isn't something I'd want to inflict
on any mesa dev who had the audacity to move a bit of code around..
but in the current state I also don't envy the task of keeping AOSP
master + mesa master working together)

BR,
-R