[cmake-developers] Forcing tests to build with dependencies

Robert Dailey rcdailey.lists at gmail.com
Fri Sep 7 13:12:24 EDT 2012


Suppose I have three targets:

A, B, and C

The structure for these on the filesystem is as follows:

Root Directory
> CMakeLists.txt
> A
>> CMakeLists.txt
> B
>> CMakeLists.txt
> C
>> CMakeLists.txt

C's CMakeLists.txt also calls:

project( C )

So now when I open C.sln or invoke make for C, it will build C and all
of its dependencies.

C depends on A & B (they are specified as link libraries, so thus a
dependency is formed -- when I build C, both A & B are built first)

Furthermore, all targets define tests. However, when I open C.sln,
only C's unit tests are present in the solution. This is because only
tests that appear *after* the project(C) call (in the same directory
and recursively) are included in the solution, and when ALL_BUILD is
invoked, the unit tests for A and B are not built.

The behavior I'd like here is that all unit tests for all targets
specified as a dependency to C (indirectly and directly) are loaded as
well. Currently there is no mechanism in CMake to allow for this
AFAIK, but for now I'd like to find a reasonable workaround.

The general use case for this is that we have a wide range of projects
in our source control repository. We usually create a project() in
some subfolder, that will only contain projects needed for our team
(we don't care about building other teams' tools & such). The issue
with this is that there is no way for us to currently only build or
work with unit tests that apply to only those dependencies we load in
our solution (except for those that happen to open simply because they
are defined after our project() call).

If there is no workaround to achieve this behavior then I'd like to
begin working on a feature that would allow this. I would like to get
ideas from everyone on what the best way to do this would be. I'm
hoping this could be a change that doesn't require any changes to the
CMake script language itself (i.e. make this behavior intrinsic), but
if we want to retain the legacy behavior then I could add an option.

I don't dive into the CMake code very often, but I can definitely do
the work if I get some help on feature design and architecture.



More information about the cmake-developers mailing list