[cmake-developers] ExternalProject: Use native paths as substitute for directory tokens
Kislinskiy, Stefan
s.kislinskiy at dkfz-heidelberg.de
Thu Aug 27 10:12:19 EDT 2015
Yes, TO_CMAKE_PATH is used quite often. Just imagine parsing paths as input. Or when you create CMake scripts during the build you might want to call file(TO_CMAKE_PATH) in there. It makes sense on both ends, as input and output. :) I also vote for consistent naming, if the generator expressions are chosen as the final solution.
-----Original Message-----
From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of James Johnston
Sent: Donnerstag, 27. August 2015 16:06
To: cmake-developers at cmake.org
Subject: Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens
> -----Original Message-----
> From: cmake-developers [mailto:cmake-developers-bounces at cmake.org]
> On Behalf Of Kislinskiy, Stefan
> Sent: Thursday, August 27, 2015 13:44
> To: Brad King; CHEVRIER, Marc; David Cole
> Cc: cmake-developers at cmake.org
> Subject: Re: [cmake-developers] ExternalProject: Use native paths as
> substitute for directory tokens
>
> This is pretty nice from the perspective of an engineer. But I wonder
> if
it
> wouldn't be kind of over-engineered in the sense that it would be a
> rather hidden feature for the purpose? -- I probably wouldn't think of
> searching
for
> a generator expression in the documentation when I have trouble with
> the replacement of directory tokens. Then again, there could be a hint
> in the ExternalProject documentation which would be fine I guess. One
> way or another, I would be happy if we could determine what the patch
> should provide exactly so that we come to an end. :-) Thank you for
> all the
feedback
> so far.
I think Brad raises an excellent point here though I hadn't thought of...
implementing the underlying functionality as a generator expression allows the problem to be solved outside of the scope of ExternalProject when it arises... For example if I add_custom_command as a custom build step and need to pass a native path argument to it - a path known only at generate time. I guess it is not possible right now?
> Another approach is to introduce a generator expression to transform
> the path slash style. Then it could be used both for ExternalProject
> and in
other
> custom commands. E.g.
>
> $<PATH_FOR_SHELL:<SOURCE_DIR>/bootstrap${shell_ext}>
>
> In this case <SOURCE_DIR> would be replaced with forward slashes by
> ExternalProject but then at generate time CMake would evaluate the
> genex to convert slashes as needed.
I would vote naming it TO_NATIVE_PATH instead of PATH_FOR_SHELL, for consistency with the existing parameter in the file command. There could then also be a corresponding TO_CMAKE_PATH gen-exp, although I wonder if it would be used much. (Then again, do people even use file(TO_CMAKE_PATH) very much?)
James
--
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
More information about the cmake-developers
mailing list