Re: [Mesa-dev] [PATCH v4 0/2] build system: Unify c++11 detection and used [was: configure+mesa/st:check -std=c++11 support and enable tests accordingly]

2017-10-26 Thread Emil Velikov 
On 17 October 2017 at 16:54, Chuck Atkins  wrote:
>> I also think adding a test for each C++11 feature used in the code is
>>
>> too tedious, regardless of the build system, and it would really need a
>> dedicated maintainer.
>
>
> Certainly.  Rather than checking for everything, I think a code snippet that
> just includes a few c++11-only headers would be sufficient and just assume
> if those are there then you have a working c++11 std library.  That's all
> we're doing with the std=c++11 check anyways; i.e. we're assuming that
> there's no need to specifically check for support of range-for loops and
> lambda expressions separately.  Partial standard implementation is less of
> an issue these days I think than in the early C++11 years.
>
My take on the thread so far is - there's weird combos that will
almost always be broken.
Having brown tests and/or workarounds for everyone is impossible.

A compiler "accepting" C++11 code without having a runtime library
provided, is an interesting example.

That said, I think we can aim at:
 - step 1, cover the case that works for most people
 - step 2, if things are broken for A/B send patches clearly
documented patches - compiler, version, platform, etc.
 - step 3, don't be afraid to deprecate/remove obsolete workarounds
and do poke the affected people.

That's just a personal take of course, so take it with a healthy pinch of salt.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 0/2] build system: Unify c++11 detection and used [was: configure+mesa/st:check -std=c++11 support and enable tests accordingly]

2017-10-17 Thread Chuck Atkins 
>
> I also think adding a test for each C++11 feature used in the code is
>
too tedious, regardless of the build system, and it would really need a
> dedicated maintainer.
>

Certainly.  Rather than checking for everything, I think a code snippet
that just includes a few c++11-only headers would be sufficient and just
assume if those are there then you have a working c++11 std library.
That's all we're doing with the std=c++11 check anyways; i.e. we're
assuming that there's no need to specifically check for support of
range-for loops and lambda expressions separately.  Partial standard
implementation is less of an issue these days I think than in the early
C++11 years.

- Chuck
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 0/2] build system: Unify c++11 detection and used [was: configure+mesa/st:check -std=c++11 support and enable tests accordingly]

2017-10-16 Thread Gert Wollny 
Am Montag, den 16.10.2017, 10:31 -0400 schrieb Chuck Atkins:
> Hi Gert, Emil, 
> 
> > I think that using the -std=c++11 check should be good,
> 
> A few things to consider, neither of which is a deal breaker, I just
> want to make sure they're not forgotten about:
> #1 -std=c++ will cover many cases, but not all.  Many commercial
> compilers use a different set of options 
[...]
> #2 This only checks support for language suport, not std library
> support.  This can be problematic where your compiler doesn't have
> it's own standard library (i.e. Intel and PGI).  This puts you in a
> wierd spot where things like range-for loops work because they're a
> language feature but std::unique_ptr is not available because it's an
> std lib feature.


> Both of these are managable, #1 by looping through possible flags to
> test for and #2 by performing a test compile of C++ code using
> required library features and the compiler flags accepted by #1.  
> I would even venture to say they could be accounted for as needed,
> rather than dealt with apriori. 

Well, my second patch set was using an m4 file that did exactly that.
It would, however, only run one compile test to check whether the
features of the requested standard are available (with or without
additional compiler flags), but as Emil pointed out, nobody really
wants to maintain custom m4 files (and I myself am also far from an
expert, I just grabbed a m4 file that was on the Internet). 

I also think adding a test for each C++11 feature used in the code is
too tedious, regardless of the build system, and it would really need a
dedicated maintainer. 

> The use cases should not be forgotten though.  Neither of these are
> common on a typical end-user linux desktop but they are the norm on
> HPC / SuperComputing systems, where Mesa+llvmpipe or Mesa+swr are
> heavily relied on for rendering in cpu-only compute clusters.

With that in mind I think the best solution to accommodate these use
cases too without adding an m4 file is to add a configure flag that
makes it possible to set the c++11 enabling flag manually, and harvest
the swr compile check that tests whether __cplusplus >= 201103L with
this flag set, and maybe add some standard library feature check.

Opinions? 

Best, 
Gert

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 0/2] build system: Unify c++11 detection and used [was: configure+mesa/st:check -std=c++11 support and enable tests accordingly]

2017-10-16 Thread Chuck Atkins 
Hi Gert, Emil,

I think that using the -std=c++11 check should be good,


A few things to consider, neither of which is a deal breaker, I just want
to make sure they're not forgotten about:

   1. -std=c++ will cover many cases, but not all.  Many commercial
   compilers use a different set of options:
  - IBM XL: some versions use -std=c++11, others use
  -qlanglvl=extended0x
  - PGI: --c++11
  - Clang: older vertsions use -std=c++0x
  - Intel: Some versions use -std=c++, others use -std=c++11
   2. This only checks support for language suport, not std library
   support.  This can be problematic where your compiler doesn't have it's own
   standard library (i.e. Intel and PGI).  This puts you in a wierd spot where
   things like range-for loops work because they're a language feature but
   std::unique_ptr is not available because it's an std lib feature.

Both of these are managable, #1 by looping through possible flags to test
for and #2 by performing a test compile of C++ code using required library
features and the compiler flags accepted by #1.  I would even venture to
say they could be accounted for as needed, rather than dealt with apriori.
The use cases should not be forgotten though.  Neither of these are common
on a typical end-user linux desktop but they are the norm on HPC /
SuperComputing systems, where Mesa+llvmpipe or Mesa+swr are heavily relied
on for rendering in cpu-only compute clusters.

- Chuck
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 0/2] build system: Unify c++11 detection and used [was: configure+mesa/st:check -std=c++11 support and enable tests accordingly]

2017-10-16 Thread Emil Velikov 
On 14 October 2017 at 11:12, Gert Wollny  wrote:
> Hi Emil,
>
> regarding this patch, I now think we can indeed drop the second part
> (the one that adds the g++4.4 test), because it would only check
> whether one sets the -std=c++11 flag somewhere accidently. Checking
> that no c++11 code makes it into core mesa is already happening as long
> as travis uses a pre g++6 compiler.
>
> Considerig the choice between checking for support of the flag
> -std=c++11 and checking whether the compiler supports c++11 features by
> default the discussion on debian-devel started by this mail
>
>   https://lists.debian.org/debian-devel/2017/10/msg00174.html
>
> might be of interest. In short it is preferred that the code is
> compiled with the standard the compiler sets by default. From that
> point of view the version of the patch that checks for the features
> would be better, or I could rework the patch to check whether  g++ is
>>= 6.0, but that is, of course, not as generic.
>
> Another consideration is that with g++ >= 6 with the current approach
> of setting the flags we end up with the somewhat paradox situation
> where the "more modern" code requiring -std=c++11 is compiled like
> this, but the "older" code is compiled with the default, newer, c++14,
> so no setting flags unless it is really needed would IMHO be more
> consistent.
>
Gert, I believe that you can see why using C++ code (or tinkering with
its flags) is not as easy task.
In Mesa context at least - a low level library used by dozens if not
hundreds of other components.

Sure there's plenty of existing C++ code around, which doesn't help.

That aside:
I think that using the -std=c++11 check should be good, one small
nitpick though.

Please keep the different Mesa components as separate patches.
In semi-random order:
 1) generic check in configure
 2) use in swr (maybe squash with 1?)
 3) use in clover
 4) use in st/mesa/tests
 5) Travis build target (not 100% sure it's worth having but meh)

Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 0/2] build system: Unify c++11 detection and used [was: configure+mesa/st:check -std=c++11 support and enable tests accordingly]

2017-10-14 Thread Gert Wollny 
Hi Emil, 

regarding this patch, I now think we can indeed drop the second part
(the one that adds the g++4.4 test), because it would only check
whether one sets the -std=c++11 flag somewhere accidently. Checking
that no c++11 code makes it into core mesa is already happening as long
as travis uses a pre g++6 compiler.

Considerig the choice between checking for support of the flag 
-std=c++11 and checking whether the compiler supports c++11 features by
default the discussion on debian-devel started by this mail 

  https://lists.debian.org/debian-devel/2017/10/msg00174.html

might be of interest. In short it is preferred that the code is
compiled with the standard the compiler sets by default. From that
point of view the version of the patch that checks for the features
would be better, or I could rework the patch to check whether  g++ is
>= 6.0, but that is, of course, not as generic. 

Another consideration is that with g++ >= 6 with the current approach
of setting the flags we end up with the somewhat paradox situation
where the "more modern" code requiring -std=c++11 is compiled like
this, but the "older" code is compiled with the default, newer, c++14,
so no setting flags unless it is really needed would IMHO be more
consistent. 

Best, 
Gert 

Am Dienstag, den 03.10.2017, 16:47 +0200 schrieb Gert Wollny:
> 
> Following Emils comments I've updated the patches. 
> 
> Compiling was tested on travis on top of 677edff5cf (wayland-egl:
> rework ...) 
> plus the patch  "wayland-egl: redistribute wayland.egl.h include"
> proposed by 
> Tobias Klausmann: https://travis-ci.org/gerddie/mesa/builds/282591233
>  to fix 
> some build configurations.  
> 
> Changes versus v3:
> 
> patch 1: 
> - use AX_CHECK_COMPILE_FLAG to test for support of -std=c++11, this 
>   avoids adding a new custom m4 file
> - use if-then tests instead of calling the macro various times 
> - remove undocumented changes to .travis.yml 
> 
> patch 2: 
> - use llvm-3.3 when building with g++-4.4 since llvm-3.6 actually
> sets the -std=c++11 flag resulting in build failure with g++4.4 that
> doesn't support this flag. 
> 
> Regarding adding yet anouther build configuration to travis: 
> I propose to add this test, because mesa is supposed to support
> compilers  gcc/g++ 4.2, and -std=c++11 was not supported before g++-
> 4.7. Given that g++ >= 6 is now the standard in Debian stable and
> derivatives, and defaults to c++14, developers using these distros
> might not be aware when they add c++11 (or c++14) code.
> 
> Changes w.r.t. v2:
> - complete rewrite
> 
> best regards, 
> Gert 
> 
> Gert Wollny (2):
>   configure+mesa/st: unify check for -std=c++11 support and enable
> accordingly
>   travis: Add test for gcc-4.4 compiler tool chain
> 
>  .travis.yml   | 31
> +++
>  configure.ac  | 18 ++--
>  src/gallium/drivers/swr/Makefile.am   |  4 ++--
>  src/gallium/state_trackers/clover/Makefile.am |  6 +++---
>  src/mesa/state_tracker/tests/Makefile.am  |  7 +-
>  5 files changed, 54 insertions(+), 12 deletions(-)
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v4 0/2] build system: Unify c++11 detection and used [was: configure+mesa/st:check -std=c++11 support and enable tests accordingly]

2017-10-03 Thread Gert Wollny 
Resiedning this because I git mixed up with the patch versions, sorry.

Following Emils comments I've updated the patches. 

Compiling was tested on travis on top of 677edff5cf (wayland-egl: rework ...) 
plus the patch  "wayland-egl: redistribute wayland.egl.h include" proposed by 
Tobias Klausmann: https://travis-ci.org/gerddie/mesa/builds/282591233 to fix 
some build configurations.  

Changes versus v3:

patch 1: 
- use AX_CHECK_COMPILE_FLAG to test for support of -std=c++11, this 
  avoids adding a new custom m4 file
- use if-then tests instead of calling the macro various times 
- remove undocumented changes to .travis.yml 

patch 2: 
- use llvm-3.3 when building with g++-4.4 since llvm-3.6 actually sets 
  the -std=c++11 flag resulting in build failure with g++4.4 that doesn't 
  support this flag. 

Regarding adding yet anouther build configuration to travis: 
I propose to add this test, because mesa is supposed to support compilers 
gcc/g++ 4.2, and -std=c++11 was not supported before g++-4.7. 
Given that g++ >= 6 is now the standard in Debian stable and derivatives, 
and defaults to c++14, developers using these distros might not be aware 
when they add c++11 (or c++14) code.

Changes w.r.t. v2:
- complete rewrite

best regards, 
Gert 

Gert Wollny (2):
  configure+mesa/st: unify check for -std=c++11 support and enable
accordingly
  travis: Add test for gcc-4.4 compiler tool chain

 .travis.yml   | 31 +++
 configure.ac  | 18 ++--
 src/gallium/drivers/swr/Makefile.am   |  4 ++--
 src/gallium/state_trackers/clover/Makefile.am |  6 +++---
 src/mesa/state_tracker/tests/Makefile.am  |  7 +-
 5 files changed, 54 insertions(+), 12 deletions(-)

-- 
2.13.5

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev