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
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
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 * jhunold_at_gmx.eu ! Germany
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk