Boost logo

Boost-Build :

Subject: Re: [Boost-build] Using bjam testing rules, and boost.test with CI systems
From: Anthony Foglia (AFoglia_at_[hidden])
Date: 2010-05-19 11:31:53

Johan Nilsson wrote:
> Anthony Foglia wrote:
>> I'm setting up a continuous integration system (Hudson) for our code
>> base. It can parse the xml output from boost test. The problem is,
>> when I run the boost test code from the "run" rule, it
>> appends an "EXIT STATUS: 0" line after the XML, which causes the
>> parser to fail. Is there a way to tell run to preserve the only the
>> executable output, without the exit status line?
> I've been using Hudson + Boost.Test for quite some time now.
> IIUC you're redirecting standard output to a file, and use that file as
> input to the xUnit/Boost.Test plugin. I suggest that you instead
> explicitly configure Boost.Test to write the test log to file in one of
> the following ways:
> - Redirect the log output stream in your code using global fixtures. See
> to get started. You'll need some way of communicating the output file
> name to the test executable, but that's doable.

But I would need to set that in every test program. Perhaps if we were
doing things like that from the start, but even then, it feels rather

> - Add the command-line option "--log_sink=<path to file>" as an argument
> to the test driver. Caveat: only supported lately IIRC, haven't tried it
> myself.

This would be (almost) perfect, but it appears it was introducted in
1.42, and we're still on 1.35.

Ideally it would be a setting I could set for Hudson either directly to
Boost.Test (like BOOST_TEST_OUTPUT_FORMAT environment variables), or to
bjam. But if I set it manually, then I have the problem of different
test executables fighting over the output file (with no
synchronization). (Hence the "(almost)" above.)

I feel that somehow I should be able to tell boost build's test
functions that in the .output files I want just the output, not the

Anthony Foglia
Princeton Consultants
(609) 987-8787 x233

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