On 2014-03-06 21:47+0100 Alejandro Martinez Ruiz wrote:
Hi list,
I have a problem trying to properly install my project with CMake.
My project has a dependency on an external project, which I
conveniently download, build and install using the ExternalProject
module. What I have at this point is the following:
1) This external project produces a set of shared and static
libraries, along with related symlinks (on Unix), which I do not know
their exact names in advance, but only a pattern.
2) The shared libraries from the external project need to be installed
along with my project's binaries in the final destination, either in
the same directory or in a known rpath (ie, $ORIGIN/../lib). I don't
want to point ExternalProject's INSTALL option to the final
destination of my project, since this external project installs a ton
of extra stuff that is not needed, so I point it to a controlled
directory within my project's build tree. I guess I could actually
skip the install step altogether and link directly to the libraries
within their own build tree.
3) My project's binaries depend on the external shared libraries and I
can successfully link them against these external libraries by
declaring the libraries as IMPORTED and setting the IMPORTED_LOCATION
and IMPORTED_IMPLIB properties on them to one of the known symlinks
(ie. libfoo.so, which points to something like libfoo.so.0.2.4).
The problem arises when I try to install the shared libraries produced
by the external project. I want to include not only the files that the
binaries are actually linked to, but also all the symlinks. Since
those files do not exist at configure time, cmake errors out on
FILE(GLOB ...) and INSTALL(FILES ...) commands.
I have been able to install just the imported library to a directory
under the install prefix by using:
INSTALL(CODE "FILE(INSTALL ${SHARED_LIB_LOCATION} DESTINATION
${CMAKE_INSTALL_PREFIX}/lib")
But even if I could do that for the entire set of generated files, the
problem is that (some?) package generators completely ignore files
installed this way. This is the case with NSIS, which seems to require
a file to be installed using INSTALL() to actually include it in the
final package... but using INSTALL(CODE "INSTALL(FILES ...)") does not
work.
So basically, my question is how to properly install files which are
generated during build time (ie. external project's shared libraries
and related files) but without knowing in advance the exact name of
the files that I want to install, so that the end result will be OK
when installed manually and also picked up correctly by NSIS and
others.
Hi Alex:
To solve the issue you have described, I suggest you create a simple
overall project that configures the build of _both_ your principal
project and the project it depends on using the ExternalProject_Add
command.
For PLplot I have a more complicated case where PLplot depends on
other packages which in turn depend on further packages. So there is a
hierarchy of such package dependencies, but no circular ones. Through
the DEPENDS subcommand of ExternalProject_Add, epa_build insures that
all builds get done in the correct order (i.e., the dependencies get
configured, built, _and_ installed before the packages which depend on
them are configured). Thus, at configuration time for any one of the
packages, that package's build system can find the exact names (e.g., symlink
names for libraries) of what has already been installed by the
dependent package(s).
Your case is simpler (only one principal package and one dependency
for it), but I think the same idea should work well for it so, for
example, your principal package could copy a subset of what has been
installed (i.e, a library and symlinks for it) for its dependent
package to a new install location (which sounds like what you want to
do).
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://www.cmake.org/mailman/listinfo/cmake
