[cmake-developers] generator expression for path slash conversion

Brad King brad.king at kitware.com
Wed Sep 23 09:55:31 EDT 2015


On 09/23/2015 08:40 AM, Kislinskiy, Stefan wrote:
> I wrote the documentation, added a genex test that checks it the
> given path is converted as expected on different platforms, and
> added another ExternalProject test for Windows that invokes
> pushd, which is is command sensitive to the path style.

Thanks.  I needed to fix a typo to get the latter test to run:

-    add_test(ExternalProjectShellPathGenex ${CMAKE_TEST_COMMAND}
+    add_test(ExternalProjectShellPathGenex ${CMAKE_CTEST_COMMAND}

However, it fails when there is a space in the path because the
conversion result ends up as something like

  "\"c:\path with space\...\""

The problem is that the genex evaluates and adds the quotes and
then the custom command generator escapes the argument for the
shell again.  The problem is that ConvertToOutputFormat is meant
as the final conversion step when writing a path into a shell
command in the generator, so it quotes values with spaces and may
add other escapes ad needed for the build system script (e.g. the
Makefile).  The custom command generator will then repeat all that
with another layer.  Therefore ConvertToOutputFormat is not the
right implementation for SHELL_PATH.  I think we want just the
slash conversion to be done by the genex.

Unfortunately the proper sequence of path escaping steps depends
on the context in which the path will be written.  When using
$<SHELL_PATH:...> inside add_custom_command we want it to do
just the slash conversion because add_custom_command will take
care of the rest of the layers of escaping.  However, in case of
using file(GENERATE) for a .cmd file then we would want the
quoting too.  Perhaps we can defer that use case to later work
with a separate $<SHELL_ESCAPE:...> genex.

> I wasn't sure about the VERSION I am supposed to write into the
> cmake_minimum_required() line in
> Tests/ExternalProjectShellPathGenex/CMakeLists.txt, so I chose
> 3.3.20150923.

That's fine.

Thanks,
-Brad



More information about the cmake-developers mailing list