Re: [Boost-build] switching on toolset

Subject: Re: [Boost-build] switching on toolset
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-06-20 08:00:30

On 6/17/2015 11:25 AM, Robert Ramey wrote:
> On 6/16/15 9:01 PM, Gennadiy Rozental wrote:
>> Edward Diener <eldiener <at> tropicsoft.com> writes:
>>
>>> Look at predef-check and predef-require in the Boost predef library. It
>>> is still a bit buggy but it is what you want.
>>
>> I do not understand how to use these or what they are doing.
>>
>> For now , what I need is rather simple. If toolset is gcc with version
>> less
>> then equal to 4.6 add std=c++0x otherwise add std=c++11.
>
> would this really be a great idea?
>
> And what happens when one adds the std=c++11/... to the bjam build
> globally?  and this conflicts with your choice here?
>
> What happens when I build tests using std=c++11 and your library is
> using something else.
>
> What happens when the user want's to build the library using CMake or
> some other build system.
>
> This would mean that the functioning of the library might change
> silently dependending upon which compiler the user was using.  This kind
> of behavior leads to bugs and behavior which is maddenly difficult to
> understand.
>
> How about doing the following:
>
> a) Use the macros in config.hpp to condition code on availability of
> C++11/C++14 features.  These macros are dependent upon the std=c?? set
> by the user at the top level of bjam.
>
> b) let the user apply this switch at the top level with the toolset
> attribute and let all the libraries follow this setting.  This will
> guarentee a consistent/unambiguous setup.

The sort of change being discussed is for running the unit tests of a 
particular library. Can those who run regression tests specify different 
settings for the compiler being used for each library ? If a regression 
test needs specific settings for particular libraries to have any chance 
of running the tests without failures why do you see putting the needed 
settings into the test jamfile as wrong ?

>
> If it were up to me, bjam would give and error/warning if some lower
> level attribute setting conflicted with a previously set attribute
> value.  This would prevent these kinds of problems.  It would also make
> what you want to do impossible to do - which in my view would be a good
> thing.