[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