[cmake-developers] Strange behaviour with install(EXPORT)
Brad King
brad.king at kitware.com
Mon Jul 27 14:56:26 EDT 2015
On 07/27/2015 01:39 PM, Alex Merry wrote:
> issue is in trying to populate IMPORTED_LINK_DEPENDENT_LIBRARIES for the
> exported target, it wants the private dependencies as well as the interface
> ones. So it wants FooDep to be EXPORTed, even though this may be a private
> internal library.
Yes, this is needed for the -rpath-link linker flag to be populated
correctly.
> However, removing the PUBLIC dependencies of FooMain suppresses this error,
> presumably because the INTERFACE_LINK_LIBRARIES property is not set, so
> cmTargetInternals::ComputeLinkInterfaceLibraries does not set
> iface.ExplicitLibraries for the target, so
> cmTargetInternals::ComputeLinkInterface does not add anything to
> iface.SharedDeps, which is what is used to populate
> IMPORTED_LINK_DEPENDENT_LIBRARIES.
>
> This difference in behaviour does not make sense. So either neither
> case should be an error, or both cases should be.
Interesting.
IMPORTED_LINK_DEPENDENT_LIBRARIES was first created along with
IMPORTED_LINK_INTERFACE_LIBRARIES, the predecessor to the modern
INTERFACE_LINK_LIBRARIES. At the time the only two choices for
shared library dependencies were:
* Everything is listed in IMPORTED_LINK_INTERFACE_LIBRARIES, or
* The public subset is listed in IMPORTED_LINK_INTERFACE_LIBRARIES
and the rest (private subset) in IMPORTED_LINK_DEPENDENT_LIBRARIES.
The distinction between these cases was whether the shared library
target had the LINK_INTERFACE_LIBRARIES property set. Therefore
iface.ExplicitLibraries and iface.SharedDeps always went together.
With the transition to INTERFACE_LINK_LIBRARIES and the tll()
PUBLIC/PRIVATE/INTERFACE keywords more combinations are now
possible but the code for IMPORTED_LINK_DEPENDENT_LIBRARIES does
not account for them.
-------------------------------------------------------------------
The error on not exporting private dependencies has received
complaints before. Technically it is necessary to properly
populate the -rpath-link flag when a shared library has
dependencies that are not next to it and not in a standard
location, but often it is not necessary in practice. I think
we once discussed dropping the error and populating the
IMPORTED_LINK_DEPENDENT_LIBRARIES property only with private
dependencies that happen to be available in the export set.
The discussion may be in the dev list archives but I don't
recall when/where.
-Brad
More information about the cmake-developers
mailing list