Subject: Re: [boost] How to make tests building faster?
From: Mateusz Åoskot (mateusz_at_[hidden])
Date: 2011-12-21 12:48:09
On 20 December 2011 19:22, Robert Ramey <ramey_at_[hidden]> wrote:
> Vicente J. Botet Escriba wrote:
>> Le 20/12/11 14:39, Mateusz Loskot a Ã©crit :
>>> I'm looking for any piece of advice on the issues discussed above:
>>> - How to cut down build time of tests?
>>> - How to improve test output report
>>> Â Â (and keep it suitable for Boost regression testing framework)?
>>> - Is it advised to switch to use Boost.Test features to manage suites
>>> and test cases?
>> I started using Boost.Test and I abandoned it because Boost.Test was
>> broken on cygwin since I don't remember which version and the report
>> of individual tests doesn't appear in the regression tests. Of course
>> I would use it if Boost.Test is supported on this platform and the
>> regression test report takes care of individual tets.
>>> Â Â (I tried to figure it out browsing tests of other libs, but it
>>> doesn't indicate any preferred practice).
>>> I'd be thankful for any insights.
> Here's an idea - TEST LESS.
Sounds familiar :)
> Here is what I do:
> a) on my local system I run my current version of the serialization
> library against the Boost Release Branch. Â I do this by changing
> the directory of the serialization on my local system to the trunk
> while leaving the rest of boost on my local system as the release
> branch. Â This effectively tests my next version of the serialization
> library against the "next" release. Â This has a bunch of advantages:
I'm interested in your practice here.
How do you do the "changing the directory of the serialization"?
Do you copy and overwrite, use symlinks?
> 1) I control when the other boost components change by updating
> the release branch on my local machine only occasionally - like
> before a check -in. Â So usually, not all of my tests have to be rebuilt.
> Normally it's only the one that's required to test the header I actually
> changed. Â If I make an improvement on one test, only that test get's rebuilt.
> 2) I'm testing against "known good" components - the next release branch.
> Doing things this way lets one use boost test without overloading the
> boost test developer with the responsability to have is version in the
> trunk bug free and rock solid all the time - which is not what
> the trunk is for.
I have to admit, I have been too lazy to use branches/release that way.
Anyhow, this approach sounds very reasonable and I've got new bigger
hard drive now,
so no excuse.
> Try this out - it will help a lot.
I will. Thanks!
Your approach combined with John's suggestion to use PCH should be a
nice time saver.
Plus, I bjam jobs switch, even if I have only two cores.
-- Mateusz Loskot, http://mateusz.loskot.net