Boost logo

Boost Interest :

Subject: Re: [Boost-cmake] Testing dependencies
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2009-06-11 01:33:41

Brad King wrote:

> David Abrahams wrote:
>> I just realized we need a feature (surprise!)
>> When I'm working on a Boost library, I need to be able to fire off all
>> the tests of libraries that depend on the one I'm changing, to make sure
>> I'm not breaking anything in the library collection before I check in.
> We discussed this at length during the BoostCon meeting, right?
> Currently CTest always runs all tests, which is *sufficient* to catch
> breakages. The problem is that it is not *necessary* to run all tests.
> This is the incremental re-testing feature. CTest is not aware of any
> build-system dependencies since they are all stored in platform-specific
> ways. Making it aware would require implementing most of a build-system
> in CTest.
> The solution to this problem was the last step of those we outlined on
> the board near the end of the meeting. We need to convert all tests to
> normal build rules using custom commands created by CMake. Then full
> build-system dependencies are available and incremental re-testing is
> possible.
> This is what Troy's custom-target-per-test approach last year tried to
> do, but it was not scalable.

In what way, and why and can *that* be fixed?

> Instead all tests for each library need
> to be combined into one custom target that uses custom commands to
> drive tests. I can provide more details when the time comes.
> However, the major step before that is to package all tests for each
> library into test-driver executables. This is useful whether using
> bjam or CMake because it drastically reduces the total link time
> and disk space used for building tests.

While it definitely will result in *some* improvement in that, it
is not apparent such global and surely painful rearrangement is truly
good idea. Not to mention that somebody would have to change the current
reporting mechanisms.

- Volodya

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