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

[Rob Herring]

On Thu, Mar 23, 2017 at 5: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?

No, either way I can't keep up with it. My annoyance here was I
rebased to pickup my latest batch of fixes and something else broke.

> 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.

I've got a CI setup[1]. It's broken so much though, I haven't started
spamming the list with reports. I can't find new problems if the tree
stays in a state of brokenness.

> Is your suggestion for Mesa developers to gate their patches on
> updating the Android build system?

For trivial cases, yes. This one even had the change described in the
thread and the fix doesn't even touch Android build files. At least
have some coordination with various folks who do care and can fix
things. Maybe we can provide fixes before things are committed.
Minimally we can start fixing things when patches are under review
rather than after being committed and after CI build breaks.

Rob

[1] https://ci.linaro.org/job/robher-aosp/