|
|
Boost Interest : |
Subject: Re: [Boost-cmake] Testing dependencies
From: Brad King (brad.king_at_[hidden])
Date: 2009-06-11 08:50:55
Vladimir Prus wrote:
>> 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?
Troy's solution used one add_custom_target() for each test. This
translates into one .vcproj file per test on Visual Studio. Then
the IDE takes 10 minutes to load because there are so many tests.
One of the goals of CMake is to let developers work in their own
environments, so we need these projects to be viewable in the IDE.
(I keep using VS as an example, but this applies to all the IDEs.)
On the Makefile side, CMake keeps global inter-target dependencies
in one makefile. Normally it is not too big because CMake-based
projects tend not to have too many top-level targets due to the
problem with Visual Studio. However with a large number of these
targets the global dependency Makefile becomes large and slow.
While the design of this top Makefile could be improved somewhat
for scalability, it would not help the problems on the VS side.
Instead we should have one add_custom_target() to do all the tests
for a single library (e.g. function). Within the target there would
be file-level rules created by add_custom_command(). This will
translate to one .vcproj file per library that contains a bunch of
rules to drive the tests (with proper dependencies).
The above is only half the story. It is concerned only with driving
the *running* of test executables. The problem below is about
*building* them. (This applies to everything except compile-fail
and link-fail tests.)
>> 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.
Each add_executable() creates a .vcproj file in Visual Studio. The
IDE does not support multiple executables per project file. If every
test is its own executable the number of top-level targets grows
large and scales beyond the practical capabilities of the IDE.
The solution is to link all the object files for all the tests related
to one library into a single executable. If the library is not header-
only then the executable will link to it also. This drops the number
of top-level targets down to one per library. I describe details in
a separate response to Beman's post.
-Brad