Re: [boost] [test]portability of data test cases and build issues

Subject: Re: [boost] [test]portability of data test cases and build issues
From: Jürgen Hunold (jhunold_at_[hidden])
Date: 2012-11-05 09:29:32

Hi Gennadiy,

On Monday, 5. November 2012 12:00:16 Gennadiy Rozental wrote:
> Vicente J. Botet Escriba <vicente.botet <at> wanadoo.fr> writes:
> > I use to do the following without any issue
> > 
> >            [ run ../example/a_test.cpp ]
> 
> I already do something like this (in my case [ glob test_datasets/*.cpp ],
> but if target name is thew same as directory name it will fail to build on
> linux.

Interesting. Bug or feature. Can you post a minimal testcase to the 
Boost.Build ML ? 

> > Wow, I'm really surprised you have troubles with this. You need to
> > define your toolsets in the user_config.jam file. I have for example
> > 
> > using gcc : 4.7.1  : /usr/gcc-4.7.1/bin/g++-4.7 ;
> > using gcc : 4.7.1x : /usr/gcc-4.7.1/bin/g++-4.7 : <cxxflags>-std="c++11" ;
> > 
> > Someone has been requesting the addition of a 'std' feature that gives
> > the standard, but I don't think this has been implemented or even
> > retained.

See comments below. Right now using c++11 is a real mess. 

> Why do I need to introduce new toolsets? toolset gcc, gcc-4.7, gcc-4.6
> already works fine. Moreover the main point is to make it work on
> regression tester box, not mine. I need to eliminate failures in regression
> table. I want to pass std option (different one) to compilers which support
> it and ignore test on compilers which do not have it.

That is definitely the wrong direction. This breaks as soon as the compiled 
library API depends on the c++ standard.

> I can probably get
> the same result by ifdefing the code, but I'd rather have it marked
> unsupported in regression table instead of fake pass.

That is the way the go.

Unfortunately, there are only two ways to archive this:
1) special toolsets
2) an extra feature for different standards.

Option 1) is a no-go as we can't enforce uniform toolset names. Even the 
dependency on the toolset name is bogus, as people can use _anything_ for 
version identifiers. Not to mention strange cross-platfrom toolset names...

2) would enable you to add something like <std>c++11 into the requirements of 
your tests. Those would then be skipped for older compilers. And this should 
result in an empty entry in the test matrix.

Just for the record:

I've tried to inject "<build>no" requirements into the dependency chain for 
builds missing the <cxxflags>-std=gnu++11 (c++11 with gnu extensions used here) 
but this is to late in the evaluation process. Injecting "<cxxflags>-
std=gnu++11" does not work either. Raw experimental patch attached for 
critique and/or enhancement.

I think we need

feature std : c++98 c++03 c++11 : propagated ;

and then some lofig for at least gcc which sets the appropiate options 
depending on the real compiler version queried by "gcc -v" (already done for 
darwin).
For msvc, one could do

feature.set-default std  : c++11 ;

for msvc 11.0 and above. Perhaps even msvc-10.0, I have not used this one.

The gcc users (especially test runners) could then use "std=c++11" in order to 
get a clean separate build tree. And library test could detect via 
requirements.

Further comments appreciated.

Yours,

Jürgen 
-- 
* Dipl.-Math. Jürgen Hunold  ! 
* voice: ++49 4257 300       ! Fährstraße 1
* fax  : ++49 4257 300       ! 31609 Balge/Sebbenhausen
* jhunold_at_gmx.eu             ! Germany