[Mesa-dev] swr forces c++11 for whole compilation

[Ilia Mirkin]

On Wed, Apr 13, 2016 at 8:48 AM, Jose Fonseca <jfonseca at vmware.com> wrote:
> On 13/04/16 11:43, Ilia Mirkin wrote:
>>
>> Hi Tim,
>>
>> It seems like building swr forces c++11 mode for the whole build, even
>> other drivers being built that aren't necessarily ready for it.
>> Unfortunately c++11 isn't backwards compatible with c++03, so the switch
>> can't be made unilaterally. Could you have a look at why this is
>> happening?
>>
>> An example of something that does this properly is clover, which also
>> requires c++11 to be built.
>>
>> Thanks,
>>
>>    -ilia
>>
>
> Ilia,
>
> Even before SWR was merged and today's isinf fix was commited,
> nv50_ir_ra.cpp already has code to make it portable for C++11 (see below).
>
> I honestly don't understand what you're trying to achieve with this
> thread...

Build options required for a specific driver to stay with that driver
and not affect other drivers.

>
> Are you seriously plan to require C++03 to build nouveau?  It would be
> insane try to do that once GCC 6 is widely available.

-std=c++03 (or something like that) will presumably work just fine?

>
> Rather than see you swimming upstream, I much rather see you helping me
> helping you to keep nouveau C++11 portable...

That'd be nice, but to be perfectly honest, I haven't kept up with all
the changes in C++11, as my professional work has caused me to stray
from my (preferred) C/C++ roots. From what I understand, on top of
syntactic and library changes, it also changes the semantics of how
things are passed around, as part of adding the FooType&& concept. I
don't really want to go back and audit everything to make sure it's
happy with C++11.

>
> Jose
>
>
> $ git grep -C3 __cplusplus
> src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
> src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp-#include <algorithm>
> src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp-#include <stack>
> src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp-#include <limits>
> src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp:#if __cplusplus >=
> 201103L
> src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp-#include <unordered_map>
> src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp-#else
> src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp-#include
> <tr1/unordered_map>
> --
> src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp-
> src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp-namespace nv50_ir {
> src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp-
> src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp:#if __cplusplus >=
> 201103L
> src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp-using std::hash;
> src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp-using std::unordered_map;
> src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp-#elif !defined(ANDROID)

This was all added by people trying to get nouveau to build on
android, which on top of everything was variously incompatible with
itself. I understood these to be "clang is sad" types of issues (e.g.
is missing tr1) and was a workaround that I felt no need to maintain
or worry about. (But obviously I don't go out of my way to break it
either.) It's nicely self-contained, and general code doesn't have to
worry about it. (That was not the first version of the logic that was
sent -- I made them change it around until it was such.)

> --
> src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp- bestScore = score;
> src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp-            }
> src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp-         }
> src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp:#if __cplusplus >=
> 201103L
> src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp-         if
> (std::isinf(bestScore)) {
> src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp-#else
> src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp-         if
> (isinf(bestScore)) {

This, on the other hand, is common nouveau code. If I have to think
about all the possible scenarios for these things, I'm going to go
even crazier than I already am.

If someone wants to add a c++11_math.h helper which defines std::isinf
for C++<11, that'd be fine with me as well.

None of that excuses compilation options from one driver leaking over
into another driver.

  -ilia