Re: [cmake-developers] generator expression for path slash conversion (was: ExternalProject: Use native paths as substitute for directory tokens)
On 08/31/2015 09:35 AM, Kislinskiy, Stefan wrote: > As there is already a patch for such a genex in bug 15509 and the > discussion in 5939 (both linked below in Brad's reply) started 7 > years ago... It would be a great pity to let this issue seep away > again. What can I do to help fixing this finally? Someone will need to think through and propose a specific genex that does the path conversion that makes sense in this context. I think something like $ may be appropriate. For referencing command line tools (as argv[0]) the C++ side uses code like this now: this->ConvertToOutputFormat(ccg.GetCommand(i), SHELL) This genex should map to the same conversion internally. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] generator expression for path slash conversion (was: ExternalProject: Use native paths as substitute for directory tokens)
On 08/28/2015 04:06 AM, CHEVRIER, Marc wrote: Offering generator-expressions is a very good idea because it offers a global solution to this problem. Now regarding the name of the generator, may be TO_NATIVE_PATH is not judicious, (even if problems explained in http://www.cmake.org/Bug/view.php?id=5939 are, in my point of view, linked to platforms not well handled rather than wrong semantic of TO_NATIVE_PATH) but PATH_FOR_SHELL is, as well, ambiguous at least for two reasons: * commands defined in add_custom_command, for example, are directly executed without any shell evolved No, add_custom_command results in a generated build system rule for the specified command, and that always runs in a shell at build time. One can see the conversions done properly internally to CMake for generating references to source and object files on toolchain command lines, for example. * A system can have multiple shells supporting different paths syntax. For example, on windows, my shell is tcsh which handle paths with '/' rather than '\' It would be defined as the shell in which the build system will run the commands. We should choose a name accordingly. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] generator expression for path slash conversion (was: ExternalProject: Use native paths as substitute for directory tokens)
Sorry for the false assertion. I assumed, wrongly, that add_custom_command had same behaviour as execute_process for which the doc clearly explains that System API are used (no shell used). So, adding some precisions on how add_custom_command (and add_custom_target I presume) launch specified commands should be a nice enhancement. Marc On 28/08/15 15:59, cmake-developers on behalf of Brad King cmake-developers-boun...@cmake.org on behalf of brad.k...@kitware.com wrote: On 08/28/2015 04:06 AM, CHEVRIER, Marc wrote: Offering generator-expressions is a very good idea because it offers a global solution to this problem. Now regarding the name of the generator, may be TO_NATIVE_PATH is not judicious, (even if problems explained in http://www.cmake.org/Bug/view.php?id=5939 are, in my point of view, linked to platforms not well handled rather than wrong semantic of TO_NATIVE_PATH) but PATH_FOR_SHELL is, as well, ambiguous at least for two reasons: * commands defined in add_custom_command, for example, are directly executed without any shell evolved No, add_custom_command results in a generated build system rule for the specified command, and that always runs in a shell at build time. One can see the conversions done properly internally to CMake for generating references to source and object files on toolchain command lines, for example. * A system can have multiple shells supporting different paths syntax. For example, on windows, my shell is tcsh which handle paths with '/' rather than '\' It would be defined as the shell in which the build system will run the commands. We should choose a name accordingly. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
