Subject: Re: [Boost-build] switching on toolset
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-06-20 12:03:12
On 6/20/2015 10:21 AM, Robert Ramey wrote:
> 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.
I think that is what the OP intends.
> 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 ?
> 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.
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
> 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 ?
> 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.
> 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 acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk