[CMake] How do you handle recursive dependencies in CMake

[Alan W. Irwin]

On 2016-06-30 10:59+0200 Sven Baars wrote:

> 2)  ExternalProject which will grab a repository and build it.
>
> This will not work. One of the projects I use is Trilinos, which has
> build of around 1GB. I don't want to pull and build that for every
> project I have. Also the build flags that are used sometimes differ per
> machine, not per project, so it would be nice if I could build it only
> once per machine.
>
> Also, in a more generalized sense, this would also mean that every
> project I pull with ExtenalProject should also pull its own dependencies
> with ExternalProject. So then if every project on my system used CMake,
> this would mean that I would recursively rebuild my entire system for
> every project I have. This doesn't seem right.

Hi Sven:

I am chiming in late on this thread because I became aware of it only
recently.

My advice is to look again at ExternalProject because there are some
misconceptions above.  For example, in my epa_build superproject I use
ExternalProject to build a whole set of different projects (some with
CMake-based build systems some with autotools-based build system) that
interdepend on each other in a large tree of dependencies and which
also have external dependencies that must be installed on the machine
that are not controlled by my epa_build superproject. ExternalProject
allows you to set up dependencies between those epa_built projects so
they are built and installed only once and only if needed directly or
transitively by the particular epa_built "starter" project the user
specifies.  I have implemented a useful CMake function so that each
project that I make part of epa_build typically only needs to know
what other epa_built projects it depends on and the location of the
source code to be downloaded for the project.  So the epa_build
CMakeList.txt files that are required to describe each project tend to
be quite short.

For epa_build I do simplify my life by using two common install
locations (one for the build tools that are epa_built, one for the
libraries that are epa_built) for every project that I build and
install with epa_build.  So that vastly simplifies the find issues for
the dependencies which are epa_built projects themselves.  The
external dependencies (not under epa_build control) for each project
are a different story, but in my case those are largely system
dependencies found in the expected location.  So the result is I have
virtually no find issues at all with epa_build.

To learn more about epa_build see
<https://sourceforge.net/p/plplot/plplot/ci/master/tree/cmake/epa_build/>
or the latest release of PLplot.  (I originally set up epa_build so
that I could straightforwardly build the latest versions of PLplot
dependencies to test PLplot against those rather than being limited to
testing PLplot against dated system versions of its dependencies.  But
I now use it for any software that I like to build for myself.)

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________