On 2016-01-28 23:25+0100 Pau Garcia i Quiles wrote:
On Thu, Jan 28, 2016 at 9:58 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca>
wrote:
Your experience is contrary to mine. For example, in my epa_build
project (where I build all the many prerequisites of PLplot) I build a lot
of
different libraries (such as Qt5 and the GTK+ stack of libraries) using
ExternalProject_Add, and I don't experience any difficulties using
find_package to find the installed results.
I assume find_package should work well with ExternalProject_Add for
you as well so long as (a) all your ExternalProject(s) are configured
to do both a build and install (not just a build), and (b) you are
being careful in server/CMakeLists.txt to set PATH,
CMAKE_LIBRARY_PATH, CMAKE_INCLUDE_PATH, and PKG_CONFIG_PATH
consistently with the install prefix used for the ExternalProject(s).
It works well for you because you actually have two things there:
- PlPlot
- A superbuild that builds the dependencies required to build PlPlot,
and then, PlPlot itself by way of ExternalProject_Add (using
download_command = copy the source code from some directory to another)
Hi Pau:
Yes, that is a good summary, although I would add that all the
dependencies are handled properly. So the result is you can epa_build
any library (such as PLplot) within the epa_build project and the
subset of the epa_builds corresponding to its dependencies
automatically occur first, but only once (unless some change is made
in one of the dependent epa_builds). The dependency handling for a
given project is a bit complex, but, as you might expect, the
dependency logic is essentially identical for each project so I could
implement it using a CMake function. So the net result is the
CMakeLists.txt file for each epa_build project is quite short
consisting of establishing the list of dependencies, calling the
dependency-handling function, setting up ExternalProject_Add for a
given project, and then calling that routine.
But what I would like to do with ExternalProject_Add (and please note this
is a different topic than what I started the thread for) is to avoid that
superbuild:
You do have to build and install the external software once in any case so I
suspect your motivation to avoid the "superbuild" is it keeps getting
unnecessarily repeated in your case. But that should not be an issue if you
deal
with the dependencies correctly, see remarks above.
I do take your point this is a different topic than your original one so
if you want to continue this discussion, we should probably do it off list.
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
__________________________
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
