[cmake-developers] conditionals in generator expressions

Stephen Kelly steveire at gmail.com
Wed Aug 22 18:12:15 EDT 2012


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.

>> I tried this, but it made (5) below not work anymore. The generator
>> expression was evaluated too early it seems for Qt5::Core, and at that
>> point TYPE == SHARED_LIBRARY.
> 
> Way back when we discussed the $<TARGET_PROPERTY_...> expressions
> we concluded that the target could be implicit because they are
> always evaluated in the context of a target.  However, in the case
> of linking there are multiple targets involved so we do not know
> which one the user may mean.

I think it's something we can just define, is it not? We can say that in:

target_link_libraries(foo
    $<EXP1>
)

target_link_libraries(foo
  LINK_PRIVATE
    $<EXP2>
  LINK_PUBLIC
    $<EXP3>
)

target_link_libraries(foo
  LINK_INTERFACE_LIBRARIES
    $<EXP4>
)

EXP1 and EXP2 are evaluated only on foo. EXP3 is evaluated on foo, but also 
on any target that depends on foo, - either directly, or because of foo 
being included in the LINK_INTERFACE_LIBRARIES of another target. EXP4 is 
evaluated only on other targets but not on foo.

This follows the same logic as the rules for linking. So, if we can document 
it as the same, we do know what the user means.

> 
> In (5) you need to delay evaluation of generator expressions as
> long as possible, essentially until the computation of the final
> link line for a specific target.

Yes. Only the content of LINK_INTERFACE_LIBRARIES needs to be treated that 
way though.

> The same expressions may be
> evaluated multiple times in different contexts and yield different
> results e.g. link Qt5::Core into a GUI and a non-GUI executable.

Yes.

> Delayed evaluation means we need to handle list expansion cleanly.
> One approach is to try to re-work all the above-named methods to
> keep the original link information in pure-string form instead of
> performing ExpandListArgument early.  The target_link_libraries
> command would set a string-valued LINK_LIBRARIES target property
> instead of recording some internal C++ structure, just like the
> LINK_INTERFACE_LIBRARIES property.  This conversion would be
> similar to the INCLUDE_DIRECTORIES target property behavior we
> recently introduced.  Add an interface in cmGeneratorTarget to
> evaluate generator expressions in the LINK_LIBRARIES and
> LINK_INTERFACE_LIBRARIES properties given the context of some
> target for which the final link library list is being computed.

Yes, this sounds workable. It's also a lot of effort though :).

I think I'll defer it for now and work on making generator expressions work 
for include directories and compile definitions and looking into creating 
INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_COMPILE_DEFINTIONS. I think most 
of that is realistic for 2.8.10. I'll try to find the bugs for that stuff in 
the backlog tomorrow and assign them to me and put them on the roadmap.

Finding out what new generator expression conditions are needed might also 
fit. I'm not certain about the TARGET_PROPERTY_BOOL and 
TARGET_PROPERTY_STREQUAL. I think it might be better to introduce  
$<BOOL:...> $<STREQUAL:lhs==rhs> and $<TARGET_PROPERTY:prop> and then be 
able to use eg:

$<$<BOOL:$<TARGET_PROPERTY:WIN32_EXECUTABLE>>:Qt::WinMain>

$<$<STREQUAL:$<TARGET_PROPERTY:TYPE>==EXECUTABLE>:QtFoo>

 (... APPEND COMPILE_DEFINTIONS    
    "$<$<CONFIG:Debug>:LOCATION=$<TARGET_PROPERTY:TYPE>>")

This would mean I can avoid the explosion of TARGET_PROPERTY_FOO as well as 
a separate TARGET_PROPERTY for literals in the RHS, which is also needed 
anyway.

What do you think?

Thanks,

Steve.





More information about the cmake-developers mailing list