[cmake-developers] Generator expressisons in target properties

[Brad King]

On 11/06/2012 02:07 PM, Stephen Kelly wrote:
> Brad King wrote:
>> How do you propose to trigger this policy warning?
> 
> True, I don't know how to warn about it. Does that mean that a policy is 
> entirely unsuitable?

It may still be suitable, just hard to implement.  The handling of
the old property names discussed below may influence how we have to
activate the new behavior anyway.

>> I don't think we should honor both properties at once.  If the new
>> name is set the old names should be ignored (perhaps with a warning if
>> an old name is set too).
> 
> That could be an option. I think it gets complicated though. 
> 
> 1. In my branch I made tll() populate the INTERFACE_LINK_LIBRARIES prop

That opens a big can of worms because now activation of new interfaces
for these features does not depend on modification of projects using the
old interfaces.

An export generated with the new interfaces in it will not be understood
by an older CMake.  This is okay if activation of new interfaces is
explicit and intentional.  The user has then declared they are willing
to require 2.8.11 for downstream consumers.  If activation is implicit
then the generated export files must be able to work with either older
or newer CMakes.

I think 2.8.11 will have to generate export files that provide both
old and new interfaces.  The choice will be made when they are loaded
and depends on whether the application has also activated support for
the new interfaces.

The question remains how to make activation explicit when combinations
of old and new CMake versions are involved but automatic when everyone
requires a newer CMake.

>> Yes, interfaces should be flattened and replaced with their content.
> 
> So the INTERFACE_LINK_LIBRARIES property would be handled differently for an 
> INTERFACE_LIBRARY than a SHARED_LIBRARY. I think that's a bit confusing. 

An interface wrapping around a single other library should be equivalent
to defining the interface directly on that other library.  The logical
name of the interface target is kind of like a generator expression when
referenced in INTERFACE_LINK_LIBRARIES.  Wherever it is you process the
generator expressions, first transform "myinterface" to
$<TARGET_PROPERTY:myinterface,INTERFACE_LINK_LIBRARIES> or something
like that.

> What I'm proposing is removal of an existing optimization, but ok I'll go 
> ahead and do that.

I meant the "optimize later" as general advice.  Just remove the
current optimization because it is in the way of correctness of
your change.  Only if future profiling shows that the optimization
is worthwhile should it be restored.

-Brad