[cmake-developers] conditionals in generator expressions

[Stephen Kelly]

Stephen Kelly wrote:

> Brad King wrote:
>>>> It should be in cmTarget::ComputeLinkImplementation at this line:
>>
>> If it is not that early then we need to consider the interaction
>> of at least these pieces:
>>
>>cmTarget::GetLinkerLanguage
>>cmTarget::GetLinkClosure
>>cmTarget::ComputeLinkClosure
>>cmTarget::GetLinkImplementation
>>cmTarget::ComputeLinkImplementation
>>cmComputeLinkInformation
>>cmComputeLinkDepends
>>
>> They all deal with the link libraries and need the processed
>> output of generator expressions.
> 
> Thanks for the info. There is indeed a lot to look into for the link
> libraries part of theis feature.

While investigating generator expressions for link libraries, I discovered 
a problem which might make it harder to accomplish.

Any user code which invokes 

 get_target_property(loc tgt LOCATION)

or 

 get_target_property(loc tgt LOCATION_${Config})

causes 

 cmTarget::GetLocation(const char *config)

to be called. 

That in turn causes GetLinkImplementation to be called, for which the 
linker language must be determined, for which it is necessary to know the 
targets linked to.

This is all at configure-time. 

If the targets linked to is different at generate-time, the link-languages 
might be different, and the LOCATION might even get a different value.

It seems that the generator expressions for linked targets is in conflict 
with the 'linker preference' feature. Is this a resolvable situation? 

The only option I see that might work is to extend the undefined behavior 
documentation of the LOCATION* properties to cover use of generator 
expressions with link libraries, and then try to refactor/copy the code out 
of cmTarget to cmGeneratorTarget to add the generator expressions feature.

The problem that would remain even then is that the maintainer of the build-
system doesn't have full control. A dependency could use generator 
expressions in its LINK_INTERFACE_LIBRARIES property, so even if the 
maintainer thinks he's not writing code to hit the undefined behavior, a 
dependency might. Hmm, actually that would be 
IMPORTED_LINK_INTERFACE_LIBRARIES instead, so maybe adding generator 
expressions to that wouldn't work at all anyway.

I wonder if it would work to introduce generator expression capable 
LINK_LIBRARIES and INTERFACE_LINK_LIBRARIES properties, which would be 
consistent with INTERFACE_INCLUDE_DIRECTORIES and 
INTERFACE_COMPILE_DEFINITIONS.

At generate-time their content would be used together with the information 
from target_link_libraries and INTERFACE_LINK_LIBRARIES. The downside is 
that it potentially makes the link language guessing at configure-time 
useless. People porting to use the stuff would have to set the 
LINK_LANGUAGE if they want a real LOCATION at configure-time.

That was a bit of brain-dump. This is getting messy.

I've put some work in progress for the INCLUDE_DIRECTORIES and 
COMPILE_DEFINITIONS in the interface-target-properties branch of my clone.

Thanks,

Steve.