[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