Re: [cmake-developers] Installation of imported targets

2016-06-14 Thread Brad King
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

-- 

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


[cmake-developers] Installation of imported targets

2016-06-13 Thread Elie Roudninski
I'm a CMake user for while now, and i found some limitation with the
current state of imported targets.
>From what i understand, they were introduced to manipulate _already
installed_ binary/library inside CMake in order to handle linking, etc, and
is used for example in exported project configuration file.

Another regular use case that i encounter frequently, is when you need to
build an ExternalProject (because there is no build system, or because the
buildsystem is autotools and there is no package available) for a library,
and you use imported targets to declare the library target and make it
depend on the ExternalProject target. You can then properly link with it
and build order dependency is respected.

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 problem now, is when you need to export the library ... At the moment,
you just can't do it properly. There is an ugly-tricky way that i thought
of (without testing it ...) using a second fake target, but an interface
one this time, linking with the futur full path of installed library ...
Installing it with install(TARGETS myinterfacelib EXPORT myproj DESTINATION
lib) will do nothing but you should be able to do an install(EXPORT myproj)

You can track the issue here:
https://gitlab.kitware.com/cmake/cmake/issues/14311

To solve the problem, there are many solutions, with one of them might be
being able to install imported targets and use them pretty much like
regular targets. Maybe that would make interface targets a bit useless ? In
fact mixing INTERFACE and IMPORTED targets "should" do it.
This solution could work with ExternalProject as decribed before, and even
for other use cases, like providing closed-source library already built
with your project as it is done by PF_RING for example (
https://github.com/ntop/PF_RING in userland/lib/libs)

I did my best to explain myself, but if it is still confusing or if my
english is bad, do not hesitate to respond, i'll try to do better :)

Regards,

marmeladema
-- 

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