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