[cmake-developers] INTERFACE_LINK_LIBRARIES property?

Brad King brad.king at kitware.com
Fri Jun 7 09:04:36 EDT 2013


On 06/07/2013 04:01 AM, Stephen Kelly wrote:
> I've pushed the commit to my clone again. It is not as simple as above 
> because of how the uses of the signatures are recorded, and because I 
> disallow the use of debug/optimized/general with the new signatures.
> 
> Other than that, I think it's as described.

+    "Similar target_link_libraries signatures can not be mixed.",

Okay, I think we've had some confusion due to differing assumptions
about the meaning of "old" and "new" tll signatures.  Let me be more
explicit.  For the signature policy, there are two groups of signatures:

* Group A (what I called "old" signatures):

  target_link_libraries(lhs a b c)
  target_link_libraries(lhs LINK_INTERFACE_LIBRARIES a b c)

* Group B (what I called "new" signatures):

  target_link_libraries(lhs LINK_PUBLIC a LINK_PRIVATE b LINK_INTERFACE c)
  target_link_libraries(lhs PUBLIC a PRIVATE b INTERFACE c)

The semantics of the two group B signatures are *identical*.  There
is absolutely ZERO distinction between PUBLIC and LINK_PUBLIC.

All signatures in both groups continue to support debug/optimized
keywords because their use is pervasive in find modules.

Now, the signature policy should have the following behavior:

* OLD: Group A *and* group B can be used for one lhs
* NEW: Group A *xor* group B can be used for one lhs

Let me request this a third time and more explicitly: please revert
the INTERFACE_LINK_LIBRARIES-prop topic from next and drop it until
the signature policy is ready.  Introduce the signature policy as
CMP0022.  After we've settled that topic and it is clean on the
dashboard then start again on INTERFACE_LINK_LIBRARIES.

Thanks,
-Brad



More information about the cmake-developers mailing list