On 20 December 2011 16:47, Robert Ramey <ramey@rrsd.com> 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 system.
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 runners variants. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org