[CMake] What's the best practice for a large project using multiple versions of package dependencies

Zhongle Wu zhongle.wu at gmail.com
Sun May 3 00:20:53 EDT 2015


Dear CMakers:

I'd like to have your advice for setting up CMakeLists files in a large
project where I want a top level CMakeLists.txt manages the whole build
hierarchical structure.  Suppose I have some parallel sub-projects where
one sub-project depends on VTK v5 and another sub-project depends on VTK
v6, or different version of boost library, these sub-projects may also
dependent on common sub-projects. I think it would be a common scenario in
a large project that sub-projects or modules may dependent on different
version of packages, and during the project lifetime, when a dependent
package upgrades, not all of these sub projects have to upgrade the package
version at the same time.

I think that find_xxx commands are not very friendly into detect and use
parallel versions of a package due to the global cache variables.
FindQt.cmake seems support different version though.

The ExternalProject_Add for super-build is very flexible. Although as it's
name,  it was designed initially for building external packages, it can be
used to manage your own sub projects too. Using ExternalProject_Add for
these sub-projects, I can specify different version of external packages.
But I think it is not as elegant as add_subdirectory to manage the
hierarchical structure in a single build.

Instead of using the ExternalProject_Add, some people has successfully used
python script to manage these build dependencies. But using external script
language create other inconvenient issues such as the need of sharing some
configuration variables between the external script and cmake.

So what's the best practice in a build using multiple versions of packages
under a top level CMakeLists, or simply just don't do that but splitting
your sub-projects into multiple top level CMakeLists files?

Thanks!
Zhongle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20150503/99768798/attachment.html>


More information about the CMake mailing list