Re: [Boost-build] switching on toolset

Subject: Re: [Boost-build] switching on toolset
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-06-20 12:52:35

On 6/20/15 9:03 AM, Edward Diener wrote:
>>
>> What I see as wrong is having the settings automatically and invisibly
>> change without the test runner knowing about it.
>
> I don't understand this ? If in my test jamfile I need to set C11 mode
> for any of the tests to succeed, am I supposed to tell the test runner
> about this somehow ?

In the documentation for the library.  If the test runner runs the test 
with C03 support only, then it should just fail with an error message 
which tell the test runner what he has to do differently.

>> a) Each library has it's tests which are driven by commannd line
>> switches - as they are now - so far so good.
>
> I am arguing that this is not good enough. If my library's tests need
> certain switches for certain compilers I need to set them in the jamfile
> itself.

And what happens when someone runs the tests in an unsupported 
environment?  What happens which some test runner runs it with a 
conflicting toolset switch?

>> b) If a library can't be tested for some combination of command line
>> switches, it should just quit with an error message
>
> How is a library supposed to do that from the jamfile ?

LOL - I have no idea - Boost Build is a total mystery to me for the 
reasons I've stated.  It has lot's of "automatic" behavior built in with 
the hope that it will "just work".  Which it does - until it doesn't. 
Then you find your self trolling the bjam macros to some undefined 
depthing trying to find the conflict.  This wastes huge amount of time. 
  Worst of all this behavior can change on hidden variables - os, 
compiler version, other switches, etc.... It's probably the reason that 
boost build is such a time consumer.

>> c) testing all the libraries should be just the testing of each library
>> with a common set of command line switches.  This can easily be done
>> with a simple shell script.
>
> That's fine as long as a library can set its own switches in its testing
> jamfile and command-line switches do not conflict.

Agreed - but what happens when they DO conflict.  Which takes precedence 
- the command line setting or the internal "fixed up" setting.  Your 
question above - how does the jamfile report the conflict.  This is a 
mystery to me.

Just as we have come to appreciate the problems of software which 
depends upon hidden or non-obvious variables, settings, or environmental 
features, we need to appreciate that this has also created huge problems 
in our build setup - for exactly the same reasons.

Robert Ramey