> -----Original Message----- > From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] > On Behalf Of Kislinskiy, Stefan > Sent: Thursday, August 20, 2015 09:02 > To: David Cole > Cc: cmake-developers@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 -- 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