Re: [Boost-build] switching on toolset

Subject: Re: [Boost-build] switching on toolset
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-06-20 10:21:56

On 6/20/15 5:00 AM, Edward Diener wrote:
> 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 ?

I don't see putting the needed settings into the test jamfile as wrong.

What I see as wrong is having the settings automatically and invisibly 
change without the test runner knowing about it.  What I would expect is:

a) user specifies any test restrictions/requirements in the specific 
library.

b) If the tests for a specific library are run from a "higher" place - 
global bjam - and if the requirements specified from this higher place 
should conflict with those at the library level, the the test should 
just quit with an error message so that the situation can be addressed 
explicitly by either the library author and/or the test runner.

But, come to think about it, I'm thinking that if there is a conflict, 
then the upper level bjam - is taking precedence - but fact is I really 
don't know what happens in this case.  I doubt if anyone other than 
boost build developers know this either.

Which brings us to where we really should be going:

a) Each library has it's tests which are driven by commannd line 
switches - as they are now - so far so good.
b) If a library can't be tested for some combination of command line 
switches, it should just quit with an error message
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.

This would

a) complement our modularization efforts
b) support and encourage the testing of individual libraries independently
c) be easy to understand and fix when something goes wrong.

Robert Ramey