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

James Johnston johnstonj.public at codenest.com
Thu Aug 20 09:36:46 EDT 2015


> -----Original Message-----
> From: cmake-developers [mailto:cmake-developers-bounces at cmake.org]
> On Behalf Of Kislinskiy, Stefan
> Sent: Thursday, August 20, 2015 09:02
> To: David Cole
> Cc: cmake-developers at cmake.org
> Subject: Re: [cmake-developers] ExternalProject: Use native paths as
> substitute for directory tokens
> 
> Hi David,
> 
> Example excerpt (it is not possible to change the working directory for
the
> CONFIGURE_COMMAND as it is fixed to the BUILD_DIR, which might not be
> sufficient):

This doesn't really directly have to do with your proposal, but what if an
option was added to change the working dir of the CONFIGURE_COMMAND?  E.g.
WORKING_DIRECTORY_CONFIGURE.  And suppose you'd have it recognize the
various tags like <SOURCE_DIR>, etc.  This might be useful to add to other
steps as well, and would be more portable than your solution which is using
cmd.exe-specific commands.  You'd want to audit for any resulting breakage
(e.g. does ExternalProject make assumptions that the working directory of
CONFIGURE is always the binary dir? - e.g. a relative path being used
somewhere.  And probably only allow specification of
WORKING_DIRECTORY_CONFIGURE if a CONFIGURE_COMMAND was also specified, as
the built-in commands certainly assume the default working dir.)

In your situation though, I'm not sure it's strictly needed.  From your
sample, it looks like you're building boost.  In your case what if you:

 * Use ExternalProject_Add_Step to bootstrap.  You can specify a
WORKING_DIRECTORY here.  Note one problem: you can't do out of source build
of b2, which breaks user expectations.
 * Then use ExternalProject_Add_Step to build Boost.

Yes, using _Add_Step is somewhat of a workaround, but in this case, I've
found it wasn't much of a burden at all.  In fact the only case I can think
of where it WOULD be a burden would be if the configure step is CMake.  But
then you wouldn't need to change the working directory; changing it would
break CMake.  In practice nobody will want to change WORKING_DIRECTORY
unless it's a custom command and then it's easy to use _Add_Step anyway.
That said, it might still be considered a little undesired and so maybe my
proposal above would be a better way to handle it.

Corrections from maintainers and others on the above commentary are
welcome...

> 
> set(bootstrap_cmd "<SOURCE_DIR>/bootstrap${shell_ext}"
> ${bootstrap_toolset})
> 
> if(WIN32)
>   set(bootstrap_cmd pushd "<SOURCE_DIR>" COMMAND ${bootstrap_cmd}
> COMMAND popd)
> endif()
> 
> ExternalProject_Add(Boost
>   ...
>   CONFIGURE_COMMAND ${bootstrap_cmd}
>   ...
> )

>From add_custom_command:  "If more than one COMMAND is specified they will
be executed in order, but not necessarily composed into a stateful shell or
batch script."

So I am not sure your approach will work for you even if you fix the issue
with path slashes.

James




More information about the cmake-developers mailing list