Subject: Re: [boost] How to make tests building faster?
From: Mateusz Åoskot (mateusz_at_[hidden])
Date: 2011-12-20 19:01:14
On 20 December 2011 16:47, Robert Ramey <ramey_at_[hidden]> wrote:
> Dave Abrahams wrote:
>> on Tue Dec 20 2011, Mateusz Loskot <mateusz-AT-loskot.net> wrote:
>>> I'm trying to figure out if there is anything I could do to improve
>>> compile/link-time for tests of Boost.Geometry library.
>>> Currently, the tests follow fairly canonical approach in Boost:
>>> 1) Each .cpp file defines a single test program and all local test
>>> Â Â routines are executed from test_main()
>> That's your problem right there. Â The canonical organization is
>> unfriendly to fast test times and I would not use it for my next
>> library. Â It's better to put more tests together in the same
>> executable, and more in the same translation unit.
> Hmmm - I wouldn't be crazy about this idea. Â The test
> matrix reports pass/fail often with little other information
> so putting a lot of tests in to the same executable will lose
> information. Â In general I like the idea of compilation / test.
The regression matrix issue you are pointing here is
something I'm worried about, indeed.
> I would think that longer term the approach would be
> to permit the the tests to run simultaneously on a multi-core
Sounds like jobs for Boost.Build, isn't it?
> Another idea would be to make better usage of pre-compiled
> headers. These are supported by both gcc and msvc. Â Again
> would require non-trivial changes in build/test infrastructure.
I have been contemplating idea of leaving the source code of tests
structured as it is now, but having a tool which generates some sort of
"Unity Builds" - all in single translation unit.
Perhaps, having all tests wrapped with Boost.Test macros for test cases,
it would be possible to have such feature compile-time configured by Boost.Test
with Boost.Build support to switch between many and single test
-- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org