[cmake-developers] ExternalProject_Add issue
Alan W. Irwin
irwin at beluga.phys.uvic.ca
Mon May 27 03:59:59 EDT 2013
My use case is I am implementing one overall CMake "build_projects"
project that uses the ExternalProject_Add function in a systematic way
to build potentially lots of different projects on MinGW/MSYS/Windows.
For example, if a user of this script (once finished) asked for a
PLplot build, then the PLplot dependencies, shapelib, qhull, libcairo,
Qt4, etc. would be automatically built first and those results used by
the automatic PLplot build. And similarly for ephcom (which has no
dependencies), and te_gen (which depends on ephcom and PLplot). This
script is going to make by MinGW/MSYS/Wine software testing much
easier to do, but if this approach becomes popular it could expand to a
general-purpose build script for free software on Windows.
The first issue I have encountered with this approach is the
problematic (in my view) forced ALL for the add_custom_target in the
ExternalProject_Add function. Assuming my build script becomes popular
with many projects beyond what I have outlined above, the end user
doesn't want to start a 100-hour build of all projects by simply
typing the make command by accident! Instead, those end users will
most likely want a menu of named targets (that they can obtain with
the "make help" command) to build projects (and build their
dependencies), with none of those custom targets having the ALL attribute.
To me the cleanest way to deal with this issue to implement a modified
ExternalProject_Add function for my project which (a) considers the
ALL in the internal add_custom_target as a misfeature and just drops
it or (b) adds an optional ALL argument that it passes to its internal
invocation of add_custom_target.
However, I would ideally prefer not have to maintain my own
independent ExternalProject module in the long term so would it be
worthwhile to make such a feature request (either a or b) for the
CMake version of the ExternalProject module? Of course, this would be
a backwards incompatible change in the ExternalProject_Add function
that would affect users who currently ignore the generated custom
target dependencies and simply relied on the ALL target to get the
desired external projects built with no concern about dependencies
between such builds or dependencies of their own build on those
external project builds. Are there any such users that ignore
dependencies that way? In the case of (a), they would have to write
an additional custom target with the ALL attribute that depended on
the custom target produced by ExternalProject_Add. In the case of (b)
they would have to change their ExternalProject_Add calls to add an
ALL to the argument list. If the consensus amongst core CMake
developers is the adopted solution (whether a or b or something else)
is a serious backwards incompatibility issue, then that would warrant
dealing with this change by policy. Anyhow, let me know what you
think of this proposed change, and if a positive consensus develops
for either a or b or something else, I will write up the feature
request accordingly.
As I write this, I am just about finished with translating PLplot
documentation of how to build and test shapelib on Windows into an
ExternalProject_Add call. Even from this small bit of experience I am
already pretty impressed with the ExternalProject_Add approach for
making a build script. Thus, I suspect this shapelib part of it is a
small first step in what might be an interesting but long journey.
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
__________________________
More information about the cmake-developers
mailing list