[CMake] Using a toplevel CMakeList.txt to build all sub projects at once.

Matthew Woehlke mw_triad at users.sourceforge.net
Fri Feb 7 13:08:53 EST 2014


On 2014-02-06 01:14, PCMan wrote:
> We're migrating from gtk+ to Qt and autotools to CMake and encountered
> some issues.
> There are many small modules or components in our project.
> Each of them has their own CMakeLists.txt and can be built separately.
> However, it's hard to build so many projects manually.
> So we'd like to create a toplevel CMakeLists.txt to build them all at once.
> However, the small projects depend on each other.
> For example, our project layout look like this:
>
> libqtxdg - a base lib required by others
> liblxqt - a library depends on libqtxdg
> lxqt-config - a tool depends on liblxqt and libqtxdg.
>
> To build lxqt-config, liblxqt and libqtxdg need to be "installed" first.
> So simply adding them using add_subdirectoyy() won't work.

This sounds like a classic superbuild problem.

As an alternative, you could make sure that all of your sub-projects 
build CMake package configuration files with modern exported targets¹, 
and then conditionally do a find_package for your dependencies if not 
being built from the "root build". Then each sub-project uses its 
dependencies by target name, which in theory should make transparent 
whether they're being built all from the same "root build" or 
independently. (And you won't need to install each sub-project before 
building the next.)

(¹ Even if you don't go with this overall solution, using 
exported/imported targets is good practice that I would strongly 
encourage you to pursue anyway, if you aren't already doing that.)

> Even worse, two of our components are still automake-based.
> The cmake ExternalProject_Add() command did not solve the problem that
> some of them needs to be "installed" first before others can be
> compiled.

For this you will need to use a superbuild, i.e. your dependee projects 
must also be built via ExternalProject_Add(). If the dependency projects 
aren't huge, it might be better to just port them to CMake.

-- 
Matthew



More information about the CMake mailing list