[cmake-developers] Issues with generator expressions and lists

[Stephen Kelly]

Brad King wrote:
> The argument splitting rule should remain simple: a quoted
> argument is one value and an unquoted argument expands on ";".
> What your topic needs to do is delay the expansion for unquoted
> generator expressions from configure to generate time.
> 
> The problem is that by the time the arguments get to the
> add_custom_command implementation all you have is a string and
> no information about the original argument delimiter (unquoted
> or quoted).  If we were to refactor command invocation internals
> then we could pass the information along.  This would be useful
> elsewhere for example to teach the if() command not to auto-deref
> variables whose names are inside quoted args (with a policy).

I don't think it's that simple. I've repushed the fix-genex-lists branch.

 add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/output.cpp
                    COMMAND echo
                    ARGS $<1:one> "$<1:two;three>" $<1:four;five>
                    VERBATIM
 )

now results in

 echo one "two;three" four five

but 

 set(COMMARGS $<1:one> "$<1:two;three>" $<1:four;five>)

 add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/output.cpp
                    COMMAND echo
                    ARGS ${COMMARGS}
                    VERBATIM
 )

results in

 echo one two three four five

which makes the CustomCommand test fail. I don't think it's realistic to 
wrap all strings throughout cmake to add a quoted attribute.

Maybe the solution is to leave raw list literals disallowed in COMMANDs, and 
to use a property like I did in the unit test with the 

 $<TARGET_PROPERTY:consumer,INCLUDES_PROPERTY_HACK>

Any better ideas?

Thanks,

Steve.