[cmake-developers] Policy for INTERFACE_LINK_LIBRARIES
Brad King
brad.king at kitware.com
Thu Dec 6 14:15:52 EST 2012
On 12/06/2012 08:08 AM, Stephen Kelly wrote:
> There is another twist in the tail here. The existing topic on next is not
> taking account of the case where the link implementation is the link
> interface when exporting.
Yes, of course :(
How can we ever stop exporting the old interface when it comes from the
link implementation?
> I have pushed new commits to my gitorious clone in the wip-target-interface
> branch. I also pushed the add-INTERFACE_LINK_LIBRARIES-property branch to my
> clone, which I recommend merging to next. If you give me a green light on
> that (and squash some of the commits together), I'll push the next batch of
> commits on top.
Here are some comments from a quick review. I still need to go over it
in more detail though.
In this hunk:
+ const std::string nsLib = std::string(isNonImportedTarget && !isList(lib)
+ && !isGeneratorExpression(lib)
+ ? "$<EXPORT_NAMESPACE>" : "") + lib;
How does $<EXPORT_NAMESPACE> get evaluated correctly? Currently the
cmExportFileGenerator::SetImportLinkProperty method handles the namespace
transformation when populating the old link interface information. The
namespace value is specific to each referenced target. Actually, how do
we even handle this for cross-export target references that were added
recently?
In this hunk:
+//----------------------------------------------------------------------------
+static std::string generatorIface(const std::string &value,
+ cmTarget::LinkLibraryType llt)
+{
+ if (llt == cmTarget::DEBUG)
+ {
+ return "$<$<CONFIG_Debug>:"
+ + value
+ + ">";
+ }
+ else if (llt == cmTarget::OPTIMIZED)
+ {
+ return "$<$<NOT:$<CONFIG_Debug>>:"
+ + value
+ + ">";
+ }
+ return value;
+}
the expression should be $<CONFIG_DEBUG>, not $<CONFIG_Debug>.
In the "Allow target_link_libraries with IMPORTED targets."
commit message, it says "This requires policy CMP0019 to be NEW".
However, I don't see any checks enforcing that or documentation.
Thanks,
-Brad
More information about the cmake-developers
mailing list