[cmake-developers] ExternalProject: Use native paths as substitute for directory tokens

[James Johnston]

> -----Original Message-----
> From: cmake-developers [mailto:cmake-developers-bounces at cmake.org]
> On Behalf Of David Cole via cmake-developers
> Sent: Thursday, August 20, 2015 21:21
> To: James Johnston
> Cc: cmake-developers at 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