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