[Mesa-dev] [PATCH] nir/builder: fix C90 build errors

[Rob Clark]

On Sun, Dec 20, 2015 at 10:51 PM, Connor Abbott <cwabbott0 at gmail.com> wrote:
> On Sun, Dec 20, 2015 at 10:43 AM, Rob Clark <robdclark at gmail.com> wrote:
>> On Sun, Dec 20, 2015 at 12:25 AM, Connor Abbott <cwabbott0 at gmail.com> wrote:
>>>> But, this would still be an issue for tgsi_to_nir, which I guess
>>>> wouldn't make sense in glsl/nir.  Although turns out we solve that
>>>> today by:
>>>>
>>>>   #ifdef __GNUC__
>>>>   #pragma GCC diagnostic ignored "-Wdeclaration-after-statement"
>>>>   #endif
>>>>
>>>> which we could drop with this patch.  We could ofc also stuff the same
>>>> into nir_emulate.  Tbh dropping the gcc specific pragma's and
>>>> tolerating C90 in the nir header files seems nicer.
>>>
>>> Although, dropping the pragma's also opens the door for more build breakage...
>>>
>>>
>>> It seems like tgsi_to_nir already has this hack. IMHO it would be
>>> better if you built a separate libgallium_nir.a without the
>>> -Werror-declaration-after-statement to avoid this, but if you agree
>>> with the above I guess that can wait.
>>
>> Well, I guess I'll just go w/ the #ifdef / #pragma / #endif for now..
>> although IMO it wouldn't really be such a big PITA to keep NIR headers
>> C90 safe.  I mean, after all this time it was just a couple minor
>> tweaks.  We've already spent more energy arguing about it than I think
>> it would ever take to keep the headers C90 safe.
>>
>> And, I do really think it is good idea to rebuild all the users after
>> header file changes..  and turns out if you configure your mesa to
>> build the other drivers, automake will do exactly that for you ;-)
>
> But that means that I have to build all of gallium all the time, which
> doesn't seem optimal. As long as we namespace things in nir.h with
> nir_*, and drivers don't use that internally (we've been careful with
> this in i965), we shouldn't have to test stuff with other drivers
> unless we're changing stuff in an incompatible way.

well, tbh, re-running configure takes long enough (and is not
parallelizable) that I'm surprised you even bother reconfiguring mesa
to strip out gallium.. and I guess you aren't the one building mesa on
small arm devices :-P

> Anyways, I've sent out a patch which is a proper fix for this.

thanks, will give that a spin when I get a chance (but I think I'll be
away from the computer for most of the day today)

BR,
-R

>>
>> Anyways, I do have freedreno and vc4 building w/ tinderbox so I'll
>> notice quickly enough if someone breaks something.
>>
>> BR,
>> -R