[cmake-developers] Policy for INTERFACE_LINK_LIBRARIES
Stephen Kelly
steveire at gmail.com
Thu Dec 6 15:53:21 EST 2012
Brad King wrote:
> 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?
The approach I was thinking was to deal with it the same way we deal with
LINK_PUBLIC and LINK_PRIVATE - Make it depend on the policy.
> + const std::string nsLib = std::string(isNonImportedTarget &&
> !isList(lib)
> + && !isGeneratorExpression(lib)
> + ? "$<EXPORT_NAMESPACE>" : "") +
> lib;
>
> How does $<EXPORT_NAMESPACE> get evaluated correctly?
It is replaced via a call to cmGeneratorExpression::Preprocess() which gets
called by the export code. So export(TARGETS foo NAMESPACE exp_ ...) will
use exp_.
> 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, it is specific to each export() or install(EXPORT) invocation,
right?
> Actually, how do
> we even handle this for cross-export target references that were added
> recently?
I have not looked into that yet, but I don't think it's related to this.
install(EXPORT fooTargets NAMESPACE foo_ ...)
install(EXPORT barTargets NAMESPACE bar_ ...)
should not be affected by this. Or do you have a case in mind where it could
be? Or is that not the case you are thinking of?
> the expression should be $<CONFIG_DEBUG>, not $<CONFIG_Debug>.
Thanks.
>
> 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.
That may be a left-over from a previous version of the patch.
Thanks,
Steve.
More information about the cmake-developers
mailing list