[cmake-developers] ExternalProject_Add issue

[Alan W. Irwin]

On 2013-05-27 00:59-0700 Alan W. Irwin wrote:

> 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.

Never mind, and sorry about the noise concerning this.  The current
way ALL is used with the add_custom_target command inside
ExternalProject_Add should be fine.

To clarify that, the way I have the "build_projects" project planned,
the user specifies the projects he wants built and those (and their
dependencies) are _the only_ projects that are built.  Thus, depending
on which projects the user asked for, the total build that resulted
from "make all" might only take a few minutes and would only take a
long time (e.g., the 100 hours noted above) if the user specifically
requested a project which was extremely large or which had
dependencies which were extremely large.  So the ALL attribute for the
custom target created inside ExternalProject_Add is appropriate for
whatever subset of the available projects the user desires to build.

Furthermore, I did not read far enough into the ExternalProject_Add
documentation for the first build I am implementing (which is
shapelib).  Clearly, there is an install section in
ExternalProject_Add, and, in fact, I am going to use that
functionality to finish up my configuration of the shapelib install so
the way ALL is used in ExternalProject_Add is not only appropriate but
also necessary.

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
__________________________