[cmake-developers] Generator expressisons in target properties

[Stephen Kelly]

Brad King wrote:

> On 11/07/2012 07:33 AM, Stephen Kelly wrote:
>> The generator expression content is
>> created in FooTargets.cmake and the old-style information is still
>> generated in FooTargets-<Config>.cmake
> 
> One reason we split out the FooTargets-<Config>.cmake files is so that
> multiple separate build trees could each build and install a different
> configuration over top the same install prefix.  If the libraries are
> named on a per-config basis then this can work.  The main FooTargets.cmake
> just lists the targets to be defined, and the per-config files provide
> the per-config information for whatever set of configurations happens
> to be installed.  This capability must be preserved.  If that just means
> generator expressions that cover all possible configurations are put
> in the top FooTargets.cmake file, then great.

Yes, this is the case. 

The INTERFACE_* properties are not per-config, so multiple installations 
with different CMAKE_BUILD_TYPE but from the identical source will generate 
the same FooTargets.cmake.

> 
>> So, I think using a union solves the problem of consuming and production,
> 
> An upstream written for CMake 2.8.10 that uses tll and sets old link
> interfaces is not aware of the 2.8.11 behavior.  When built with 2.8.11
> the tll will populate the new interfaces.  The old interfaces will still
> be populated too.  

> The union of these in a 2.8.11-built consumer will then
> duplicate the link information where it was not previously. 

I'm a bit confused by this line. In a union, where does the duplication come 
from? 

The upstream will generate different properties which contain duplicate 
information. Lets say this is generated:

 add_library(foo SHARED IMPORTED)
 set_property(TARGET foo INTERFACE_LINK_LIBRARIES bar)
 set_property(TARGET foo LINK_INTERFACE_LIBRARIES_DEBUG bat)

The consumer built with CMAKE_BUILD_TYPE=Debug will get 'bat;bar', as 
before.

At some point, upstream makes a decision to change and generates this:

1)
 add_library(foo SHARED IMPORTED)
 set_property(TARGET foo 
     INTERFACE_LINK_LIBRARIES bar $<$<CONFIG:Debug>:bat>)
 set_property(TARGET foo LINK_INTERFACE_LIBRARIES_DEBUG bat)

Or this if they no longer want to support old-style:

2)
 add_library(foo SHARED IMPORTED)
 set_property(TARGET foo 
     INTERFACE_LINK_LIBRARIES bar $<$<CONFIG:Debug>:bat>)

Or this if they let old-style fall by the way-side:

3)
 add_library(foo SHARED IMPORTED)
 set_property(TARGET foo 
     INTERFACE_LINK_LIBRARIES bar $<$<CONFIG:Debug>:bat,bang>)
 set_property(TARGET foo LINK_INTERFACE_LIBRARIES_DEBUG bat)

Or this if they still support old-style too:

4)
 add_library(foo SHARED IMPORTED)
 set_property(TARGET foo 
     INTERFACE_LINK_LIBRARIES bar $<$<CONFIG:Debug>:bat;bang>)
 set_property(TARGET foo LINK_INTERFACE_LIBRARIES_DEBUG bat bang)


3 is an upstream bug - they need to either do 4 or 2. It requires a decision 
to use new style anyway, so I think that's upstreams issue to deal with.


In all cases, I don't see where duplication for the consumer could come 
from. 

Thanks,

Steve.