[cmake-developers] New INTERFACE_LINK_LIBRARIES policy approach

Brad King brad.king at kitware.com
Sat Dec 22 10:22:47 EST 2012


Hi Steve,

After our "Setting include directories via target_link_libraries"
thread discussion has decided to stick with the individual properties
I've thought a bit more about how to transition the link interface
properties. I think the following will be a cleaner way to do the
new link interface properties and the transition policy.

First I'll define how the properties behave when building a target.
I'll cover exporting below.

In the OLD behavior the link interface is completely determined as
it is in CMake 2.8.10 by the LINK_INTERFACE_LIBRARIES(_<CONFIG>)
properties.  The target_link_libraries command will populate the
properties as it does now and leave the new names untouched.

In the NEW behavior the link interface is completely determined
by the new INTERFACE_LINK_LIBRARIES property.  All forms of tll()
including its LINK_INTERFACE_LIBRARIES mode will populate only
the new properties.  The old property is completely ignored.

When the property is not set (internally it is WARN) then tll()
will populate both the old and new properties.  ComputeLinkInfo
will compute both the old and new style link interfaces, warn if
they are different, and use the old one.

The new target_use_interfaces command will be allowed only on
targets created with the policy set to NEW.  This will be natural
because projects will need cmake_minimum_required(VERSION xxx) to
use the new command anyway, and that will set the policy to NEW.
The new command will only populate the new properties.  A single
invocation of it on a target will be enough to make the default
link interface empty for shared libraries.

For STATIC libraries the target_use_interfaces command
PRIVATE/INTERFACE keywords still make sense because there could
be different -I/-D for the implementation versus the interface.
Only linking must be PUBLIC always.  For STATIC libraries we can
define that the PUBLIC/PRIVATE/INTERFACE keys are ignored for
linking and that it always populates both LINK_LIBRARIES
LINK_INTERFACE_LIBRARIES.  Note that for STATIC libraries the
LINK_LIBRARIES property will not be used for anything except
build-order dependencies.  Unlike the old LINK_INTERFACE_LIBRARIES
the new INTERFACE_LINK_LIBRARIES will be used for static libs too.
That way projects can deal with the link interface for all targets
in the same way.

Now, on to exporting.  Unlike the previous iteration the policy
affects it too.

When the policy is OLD/WARN we export only the old interface and
not the new interface.

When the policy is NEW we export only the new interface and not
the old interface by default.  We can have a new property to
explicitly request that the old link interface properties be
exported.  We can either ask projects to set the old interface
properties manually for export or try to compute the values from
the new ones by pre-evaluating the generator expressions for
each configuration.  This will allow projects to support older
CMake versions for their clients if they want to, but it will
be an explicit decision.

Note that your generator expression evaluation in imported targets
will still need to handle MAP_IMPORTED_CONFIG_<CONFIG> correctly.

-Brad



More information about the cmake-developers mailing list