> -----Original Message-----
> From: cmake-developers [mailto:cmake-developers-boun...@cmake.org]
> On Behalf Of David Cole via cmake-developers
> Sent: Thursday, August 20, 2015 21:21
> To: James Johnston
> Cc: cmake-developers@cmake.org
> Subject: Re: [cmake-developers] ExternalProject: Use native paths as
> substitute for directory tokens
>
> It's exactly what I am concerned about:
>
> You're asking to change the behavior of something for EVERYONE to solve a
> problem which you have encountered. If you change it the way you have
> proposed, you will cause problems for others. It has worked the way it is now
> since ExternalProject_Add was introduced in CMake 2.8. Changing it
> unconditionally the way you propose is simply not feasible for backwards
> compatibility.
>
> I think commands that take native paths ought NOT to use the <*_DIR>
> replacement values, and instead, ought to pass in variables that contain the
> native paths in the first place.
Right, agreed that the original <*_DIR> behavior would need to remain
unchanged. But how would you know what the binary directory of the external
project is, before calling ExternalProject_Add? It's too early to call
ExternalProject_Get_Property(target BINARY_DIR). I assume that is why
<BINARY_DIR> and friends exist, as the location will be affected via various
ExternalProject parameters. From the doc:
The *_DIR options specify directories for the project, with default
directories computed as follows <snip>
Quite a set of rules follow and if one is trying to use the binary directory in
the path to some build tool, it's handy to put <BINARY_DIR> in the command.
But if you need a native path for your build tool, <BINARY_DIR> doesn't work as
Stefan Kislinskiy noted, which is why I suggested making new tokens might be a
viable alternative, e.g. <BINARY_DIR_NATIVE>?
Best regards,
James Johnston
--
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
