Subject: Re: [boost] Bug-fix volunteers: risks, downsides?
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-11-03 15:21:35
Jim Bell wrote:
> On 1:59 PM, David Abrahams wrote:
>> At Tue, 02 Nov 2010 16:16:37 -0500,
>> Jim Bell wrote:
>>> On 1:59 PM, Dave Abrahams wrote:
>>>> On Sun, Oct 31, 2010 at 9:30 PM, Jim Bell <Jim_at_[hidden]> wrote:
>>>>> Where the most instruction is needed is in building and running
>>>>> the regression tests in isolation. My method might be a bit
>>>>> unorthodox: hack run.py, then regression.py, and operate things
>>>>> just like a regression test, but without uploading data. (More
>>>>> detail later.)
>>>> That sounds much harder than simply running "bjam" in the library's
>>>> test/ subdirectory.
>>> Thanks! That does sound much easier. I didn't see that anywhere in
>>> the docs.
>> That's a cryin' shame. Everyone seems to think they need to generate
>> HTML, etc. etc. in order to run the tests, when all you need is bjam.
> Could we add a section to
> describing running tests locally? (Or at least a link to the page
> describing this?) That's the only documentation I've found (though I
> could easily have missed something).
Perfect time to insert a plug for my personal method. To test a specific
library (e.g. serialization)
a) cd to ../lib/serialization/test
b) ../../../tools/regression/src/library_test.sh (or
And you will be rewarded with and HTML table in the
which has all your test results for all platforms and combinations. Each
you rerun the tests, the column is updated. Each time you run tests
with a new set of attributes (compiler, os, variant, etc) you get a new
column added to the table.
This is my standard method for dealing with this on my own machine.
> I've burned a few hours on this. (And, more importantly, perceived it
> be a difficult thing to do in isolation.)
> Will all command lines (i.e., compiler/linker flags) be identical to
> real regression tests?
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk