Boost logo

Boost-Build :

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

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

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at