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 mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake