[CMake] Build only what you need in third party libs

David Wolfe dwolfe at fifthsally.com
Tue Dec 22 07:11:28 EST 2009


> Am I in uncharted shark invested waters on a leaky inflatable raft
> covered in cheese bait, with what I am attempting... ?

Maybe a bit. CMake isn't really intended to be used this way, AFAIK.
CMakeLists.txt files from completely different projects aren't likely to
play nice together.  A CMakeLists.txt file from one project could stomp
on global settings used by another, or define a cache variable with the
same name but a totally different meaning.

The way I've typically approached this is to use a python (or shell)
script to run cmake on each dependency and install it to a common
staging area for third party binaries/headers.  In pseudo-code,
something like this:
   - for each depdir in 3rparty_deps:
       mkdir -p depdir/build
       cd depdir/build
       cmake -DCMAKE_INSTALL_PREFIX=${3RDPARTY_INSTALL_DIR} ..
       make -j8 install

(Your post mentioned MSVC? In that case, you'd substitute something like
'devenv.exe ${depdir}.sln /project INSTALL' for the make command above.
You might need to use 'vcexpress.exe instead of devenv.exe.)

Then I make sure that my own project can find those binaries and
headers, usually by specifying something like:

   cmake -DCMAKE_PREFIX_PATH=${3RDPARTY_INSTALL_DIR} <myproj-dir>

Incidentally, if other people are working on the project, I usually tar
up the headers/binaries in ${3RDPARTY_INSTALL_DIR} and encourage
everyone else to just download them directly so they can skip the
bootstrapping step.  It's not really cost-effective for every developer
to do this, and there's risk that they'll do it slightly differently and
wind up with binaries that aren't built the same.

This has worked really well for me, but ymmv and all that.  I know a
lot of developers feel compelled to merge their project's build with the
third party dependency builds. There's probably a good reason for this,
but it seems unnecessary for our situation.  Most of our external
dependencies aren't even built using CMake, so 'CMake-ifying' everything
under one big über-build hardly seems worth it...


More information about the CMake mailing list