[cmake-developers] conditionals in generator expressions

[Brad King]

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.

David Cole and I met this morning to try to resolve this issue.
We've come up with a fairly simple and acceptable solution for
conditionals in generator expressions.  The idea is to define
a set of simple, easy-to-parse expressions that together allow
what we need.

Start with two expressions with constant behavior:

 $<0:...>    evaluates to empty string, always
 $<1:...>    evaluates to ... string, always

The "0:" and "1:" are literal and may not be anything else.
The "..." is arbitrary content except for '>'.  On their own,
these are not very helpful, but now add some condition tests:

 $<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

Each conditional test evaluates to exactly "0" or exactly "1".
Internally each allows only very restricted syntax (as in
C identifiers for potential config names, etc.).

Finally, add boolean combinations:

 $<AND:x,x,x,...>  evaluates to 1 if all x=1, else 0
 $<OR:x,x,x,...>  evaluates to 0 if all x=0, else 1
 $<NOT:x>  evaluates to 1 if x=1, else 0

where all instances of "x" must be exactly "0" or "1".

Combinations of the above expressions will do what we need:

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

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.

Comments?
-Brad