Boost logo

Boost-Build :

Subject: Re: [Boost-build] [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>> 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
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

Further comments appreciated.



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

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at