[cmake-developers] conditionals in generator expressions

Brad King brad.king at kitware.com
Thu Aug 30 10:27:56 EDT 2012


On 08/30/2012 04:33 AM, Stephen Kelly wrote:
> Other examples:
> 
> $<STREQUAL "a" " ">
> 
> $<STREQUAL "a" "\"">
> 
> Which looks like a fairly 'normal' escaping scheme from a c++ point of view.

Yes.

> because that set_target_properties signature can only take one argument 
> (there are other bug reports about this I think, but I don't recall if it's 
> changable). 

It's not changeable because the command takes alternate prop/value pairs:

 prop1 value1 prop2 value2 ...

so each value must be fully quoted.  That's one reason I created the general
set_property command.  As you point out it does not help in this situation:

> set_property(TARGET foolib 
>   [APPEND] PROPERTY INCLUDE_DIRECTORIES
>   $<$<STREQUAL "a" "\""> "/bar bat/bag">
> )
> 
> it will create a list of strings. So the const char *input to the generator 
> expression will contain a ';' separated list of strings.

The entire expression must still be quoted and have its internal syntax
escaped through the CMake language.  We could use single quotes instead:

 set_property(TARGET foolib
   [APPEND] PROPERTY INCLUDE_DIRECTORIES
   "$<$<STREQUAL 'a' '\"'> '/bar bat/bag'>"
   )

for quoting inside generator expressions.

> So the options are either: 
> 
> 1) Require the use of $<ANGLE-R> or $<COMMA> inside generator expressions
> 2) Introduce proper quoting rules. I don't think the current proposal for 
> that is readable enough to be beneficial, but with a different 
> parsing/quoting scheme not based on whitespace and "\"", it might be 
> workable.

I don't like either option.

> set_target_properties(foolib 
>   PROPERTIES COMPILE_OPTIONS
>   "$<$<CONFIG:Debug>:-Wl$<COMMA>no-undefined>"
> )

That is a good example of a reason not to use comma for separation.

> Colon is not an option because it makes the language more confusing, and 
> would require a $<COLON>, which would need to be broadly used to escape 
> 'Qt5::Core' etc.
> 
> Looking at my keyboard, how about '?' '|' '\'' '#' or '*'?

I don't think any of them is particularly readable.  Using whitespace
and quoting will allow free-form arrangement for readability.  If we
define the rules carefully so that $<> protects internal quotes then
we can go back to the if/then/else approach I previously discarded:

  "$<IF 'cond-expr' 'then-expr' 'else-expr'>"

-Brad



More information about the cmake-developers mailing list