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@gmx.eu ! Germany