[CMake] Installing generated files

[Alan W. Irwin]

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
__________________________