[cmake-developers] INTERFACE_LINK_LIBRARIES property?

Brad King brad.king at kitware.com
Wed Jun 5 10:29:57 EDT 2013


On 06/05/2013 10:02 AM, Stephen Kelly wrote:
> I think a clean break is a better idea.

Then why not have a new command for linking?  Your proposal makes
*all* the old and new tll() signatures completely separate and not
usable on a single target.  It is essentially a new command with
the same name. (I'm not really proposing a new command name here,
just pointing this out for sake of argument.)

My signature policy proposal was intended to eliminate existing
confusion caused by using the ancient signatures in combination
with LINK_(PUBLIC|PRIVATE|INTERFACE) signatures.  This signature
policy is independent of INTERFACE_LINK_LIBRARIES or its policy.
Consider implementing the signature policy first as a separate
change and then base the INTERFACE_LINK_LIBRARIES topic on it.
The two changes are orthogonal but together accomplish the goal
of an empty link interface for shared libraries by default.

Supporting EXPORT_LINK_INTERFACE_LIBRARIES will require code
changes for projects.  The signature policy won't allow them to
use the tll LINK_INTERFACE_LIBRARIES signature in combination with
the new signatures anyway, so they will have to use set_property
to populate the old LINK_INTERFACE_LIBRARIES properties to work
with EXPORT_LINK_INTERFACE_LIBRARIES.  We've already agreed that
the need for a project to do this is fairly rare and obscure.

Please use an approach that pretends the LINK_<scope> options
will be the only names in the "new" signatures.  Once we have
agreement on that then PUBLIC|PRIVATE|INTERFACE will be aliases.
That is what we discussed earlier in this thread.

-Brad



More information about the cmake-developers mailing list