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-boun...@cmake.org] On Behalf Of 
James Johnston
Sent: Donnerstag, 27. August 2015 16:06
To: cmake-developers@cmake.org
Subject: Re: [cmake-developers] ExternalProject: Use native paths as substitute 
for directory tokens

> -----Original Message-----
> From: cmake-developers [mailto:cmake-developers-boun...@cmake.org]
> On Behalf Of Kislinskiy, Stefan
> Sent: Thursday, August 27, 2015 13:44
> To: Brad King; CHEVRIER, Marc; David Cole
> Cc: cmake-developers@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
-- 

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

Reply via email to