[cmake-developers] Generator expressisons in target properties

[Stephen Kelly]

Daniel Pfeifer wrote:
> So that it is fully aware of all of its [transitive] dependencies (and any
>> includes and compile defintions requirements) and I would use it like
>> this:
>>
>>  add_executable(foo_exe ...)
>>  target_link_libraries(foo_exe boost::mpl)
>>
> 
> Yeah, I like that!!
> That breaks cycles, but it also breaks transitive dependencies, no?

I don't think so. The private::*iface targets are still there, and still 
used by downstreams as they are in the INTERFACE variants of the properties. 
They are only undocumented and considered implementation details. 

In maintenance though you'd have to keep in mind that any properties you add 
to the boost::config INTERFACE_LIBRARY would not be transitively available 
when using boost::core for example. You'd have to put the transitive 
properties on the boost::private::config_iface target instead, and the 
boost::config target would have to be a very small shell which is only 
defined as depending on the boost::private::config_iface and which has no 
other properties.

> 
> 
>> I'm not sure if there's any good alternative to the _iface targets for
>> cycle-avoidance, but if it's good enough, and can be implemented, I'd say
>> it
>> would be feature-prooven.
> 
> 
> Why do we need to avoid cycles? CMake supports recursive dependencies
> among static libraries. For header only libraries, cycles should not be
> problematic either.
> 
> I would say the graph of interfaces may be acyclic, as long as there is at
> most one shared library per strongly connected component.

Yep, CMake has logic for handling of cyclic dependencies when handling 
linking. However, the declarative processing of generator expressions in 
target properties is not able to resolve cycles (Though it does find them 
and throw an error).

Thanks,

Steve.