[cmake-developers] INTERFACE_LINK_LIBRARIES property?

[Brad King]

Steve,

In this topic we need to distinguish between two types of
warnings:

* Policy Warnings: Generated using GetPolicyWarning.  These
  should appear only when the policy is not set (WARN), and
  should be triggered in cases that involve only old-style
  code that if left unmodified would behave differently when
  the policy is set to NEW.

* Other warnings.  These can come from unexpected uses of
  the new and/or old properties regardless of the policy
  (non-)setting.

On 6/26/2013 12:24 PM, Stephen Kelly wrote:
>> It can't be triggered by "new-style" code because the whole
>> point of policy warnings is to trigger for old code not yet
>> aware of the policy and the preferred new behavior.
> 
> I'm not sure what in particular you're referring to here. Maybe it's the 
> export case I described above?

By "new-style" code I mean code written to use properties
introduced in the same version of CMake that introduces the
policy.  If such code appears in the project then clearly the
developers are aware of the new features and presumably the
existence of the policy.

The purpose of a policy is to preserve behavior for existing
project releases that pre-date developers' awareness of the
policy and its behavior change.  The warning generated when
the policy is not set (WARN) needs to be of the form:

 "CMake now prefers to do something different with this
  existing code but for compatibility we are doing the
  old thing.  Please update the project to be aware of
  the preferred behavior and tell us which one to do."

In this case old code calling only tll and install(EXPORT)
and not setting any properties explicitly will behave the
same whether the policy is set to OLD or NEW, except that
the properties exposed to external consumers will change.
The build of the project itself will not change, and even
external consumers will behave the same if they are built
with the same version of CMake.

I think the case where existing code would produce different
behavior if the policy were set to NEW without other changes
is when the project sets the old LINK_INTERFACE_LIBRARIES
properties directly instead of asking tll() to do it.

We may have to re-think the internal handling of the policy
WARN behavior in order to identify cases that should trigger
a GetPolicyWarning message.  Perhaps the following will work:

* NEW: tll sets INTERFACE_LINK_LIBRARIES and cmTarget
  computes the link interface using it.

* OLD: tll sets LINK_INTERFACE_LIBRARIES(_<CONFIG>) and
  cmTarget computes the link interface using them.

* WARN (not set): Same as OLD, but tll additionally populates
  a C++-only copy of what *would* have been put in the newer
  INTERFACE_LINK_LIBRARIES property.  Then cmTarget computes
  what *would* have been the new-style link interface and
  compares it to the actual link interface computed from the
  OLD behavior.  This comparison will indicate whether the
  behavior would change and can produce the warning if so.
  (We could also consider setting INTERFACE_LINK_LIBRARIES
  instead of using a C++-only copy under the expectation that
  the project does not know about the property anyway.)

With this approach there shouldn't be any policy warnings
generated for code that uses only tll().  This is good because
such projects do not actually need any modification for the
policy's NEW behavior to do the right thing.  For code that
uses set_property to set LINK_INTERFACE_LIBRARIES(_<CONFIG>)
directly the warning may trigger, which is good because such
projects will need modification for the policy's NEW behavior
to do the right thing.

-Brad