[cmake-developers] Installation of imported targets

Brad King brad.king at kitware.com
Tue Jun 14 09:56:54 EDT 2016


On 06/13/2016 06:12 PM, Elie Roudninski wrote:
> Everything works fine except when you need to install the imported target.
> You can't use the regular:
> install(TARGETS myimportedlib LIBRARY DESTINATION lib)
> It is not permitted for imported targets. At the moment, i usually use: 
> install(FILES ${CMAKE_CURRENT_BINARY_DIR}/path/to/myimportedlib.so DESTINATION lib)
> to install it.

The main problem is that as the importer of the target we don't necessarily
have enough information to properly install it.  Shared libraries and executables
often need RPATH updates or other (platform-specific) modifications during
installation.  Multiple files need to be installed to bring along import libraries
or soname symlinks.  Only the original build system that produces a file knows
how it should be properly installed.  Therefore installing imported targets is
not a well-defined concept.

> The problem now, is when you need to export the library ... At the moment,
> you just can't do it properly.

This is because imported targets are not meant to be exported.  You got them
from some other project, so your clients can get them directly from that other
project too.  Your package configuration file is responsible for providing the
imported targets on which your exported targets depend so that a client sees
all of them after using find_package(YourProject).  It finds the dependency
and loads its imported targets, and then loads your imported targets.  There
is no need for "re-export" of imported targets.

All this was designed with the idea that external dependencies are installed
separately.  Using ExternalProject to extend your build system and then import
a target is more of a trick than a first-class feature of CMake.  Instead we
typically have a "superbuild" project that has nothing but ExternalProject_Add
calls to build all the source trees in order and share a common installation
prefix.  Then deployment is a matter of packaging what is left behind in
that prefix after all the builds are done.

-Brad



More information about the cmake-developers mailing list