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 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers