[cmake-developers] Setting includes, defines and other usage requirements with one command

Brad King brad.king at kitware.com
Thu Jan 31 10:52:23 EST 2013


On 01/31/2013 10:23 AM, Stephen Kelly wrote:
> I left it as $<LINKED> so far so that it is a shorter string, and because 
> the implementation is somewhat simpler.

Ahh, I see you were using $<LINKED:...> even for already-defined targets.
I think that is fine during processing of the same project to keep the
strings shorter.  We still need to keep it out of the exported interface
so that we can change it later without having to keep the expression
implementation around to support old export files.  This way it never
outlives the CMake process that generated it.

> Do you think it needs to be done before merging to next?

De-duplication of $<LINKED> references can be added later but I'd still
like to see it before the 2.8.11 release so that it doesn't become a
behavior change later.

> Anything else to do before merging it?

Please add a test case for the $<INSTALL_PREFIX> evaluation error.


What is the purpose of the else case here?

+  std::string value = !isGenex ? "$<LINKED:" + lib + ">"
+                               : "$<$<TARGET_DEFINED:" + lib + ">:" +
+                                   "$<TARGET_PROPERTY:" + lib +
+                                   ",INTERFACE_" + property + ">"
+                                 ">";

If the input is already a genex isn't the author responsible for
making sure it is valid?


The documentation of <package>_NO_INTERFACES and <package>_INTERFACES
reference ${CMAKE_FIND_PACKAGE_NAME}_FIND_VERSION but the corresponding
<package>_FIND_VERSION isn't documented until further down.  Please move
the new docs to the bottom, but still above the NO_POLICY_SCOPE line.

Also the current wording of the documentation makes it sound like 2.8.11
is at fault for introducing incompatibility.  There is no need to mention
the version of CMake there.  It is the version of the upstream that
starts using the new features that causes a problem.

It should be clear that the upstream is responsible for adding the example
code to set the <package>_NO_INTERFACES variable in their package config
file when it exposes the new interfaces.  Also <package>_INTERFACES is to
be set by the downstream and used by that code in the upstream.


Then merge for testing!

Thanks,
-Brad



More information about the cmake-developers mailing list