[cmake-developers] conditionals in generator expressions

[Stephen Kelly]

Brad King wrote:

> On 06/05/2012 04:59 PM, Stephen Kelly wrote:
>> So far we don't have agreement about how this should look language-wise
>> as far as I can tell. I agree with David that stuffing it into the
>> strings harms readability.
> [snip]
>> generator_expression(myGenExpr)
> [snip]
>> The $<GENERATOR:someName> could similarly be used for defines and other
>> places where we are discussing adding this feature.
> 
> That is an interesting idea to keep in mind for the future but I think
> the implementation of it is too tricky to be in scope now.

That's a little unfortunate. I'm not familiar enough with the existing 
implementation to understand why yet that is so. 

I do see some benefits implementation-wise of your idea below though.

<snip>

>  $<CONFIG:...>    evaluates to 0 or 1 if config matches ...
>  $<LANGUAGE:...>  evaluates to 0 or 1 if language matches ...
>  $<TARGET_PROPERTY_BOOL:WIN32_EXECUTABLE,tgt>  = 0 or 1

Are you sure about this one? Given your further explanation below, and 
assuming the intention is 'link to tgt if *this has a WIN32_EXECUTABLE 
property which is True', it should rather be:

$<$<TARGET_PROPERTY_BOOL:WIN32_EXECUTABLE>:tgt>

? 

Otherwise I have failed to parse it.

<snip>

>  $<$<CONFIG:Debug>:/path/for/Debug>
>  $<$<NOT:$<CONFIG:Debug>>:/path/for/non-Debug>
>  $<$<AND:$<CONFIG:Debug>,$<LANGUAGE:CXX>>:/path/for/Debug/Cxx>

There's a lot of repetition, at least in these examples. If there's a lot 
also in the real world, it might be more maintenance burden than 
convenience. 

The fact that it is also a new language syntax that needs to be learned and 
spread might also make it not-great for adoption/uptake.

> Each individual expression is easy to define, document, and
> implement.  Each has a very strict syntax we can validate as
> part of the implementation and parsing, thus allowing future
> extensions.  They look like existing generator expressions and
> follow a functional style.

And at least if it makes sense in the future (and the parser is strict 
enough) we can implement my idea too.

Thanks,

Steve.