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
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
