> -----Original Message----- > From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] > On Behalf Of Brad King > Sent: Wednesday, August 12, 2015 14:10 > To: cmake-developers@cmake.org > Subject: Re: [cmake-developers] Setting up environment using > ExternalProject_Add > > On 08/11/2015 10:41 AM, James Johnston wrote: > > 1. CMake creates a temporary shell script / batch file (the shell > > chosen based on the platform CMake compiled for - cmd.exe on Windows, > sh on POSIX). > > I don't think CMake needs to be the one to generate this. The complexity of > the file-based or command-line-based interfaces you discussed shows that it > would be tricky to have CMake generate it. > > <snip>
OK... > > enhancing e.g. add_custom_command as I proposed might make it easier, > > as this command could be aware of compiled EXE targets. > > With file(GENERATE) the project code can easily create scripts that reference > executable targets and such. One would just need to tackle this feature > request first to get file permissions right: > > http://www.cmake.org/Bug/view.php?id=15653 Indeed; that looks like a useful feature to have to begin with, and a requirement if ExternalProject is to generate its own script... > > Therefore I do not think add_custom_command needs any hook for this. > One would simply give the script as the COMMAND. Right, obviously not needed if no "cmake -E" option is added/enhanced and if we want ExternalProject_Add (and anyone else needing custom targets) to make their own script... > > > we'd want to add features to ExternalProject that use the new CMake > > functionality to finally solve the original problem. > > Yes, this part certainly needs an update to ExternalProject. Currently when > one specifies an individual <step>_COMMAND like CONFIGURE_COMMAND, > then one could simply give it the environment-set-and-launch script directly. > What ExternalProject needs is an interface to specify the environment- > setting script for use around otherwise default-generated commands for > each step. For example, a <step>_ENVIRONMENT setting (which is perhaps > not allowed in combination with <step>_COMMAND). > This approach is similar to your original alternative (3). I'll explore that option some more, after the feature you linked to is addressed. " one could simply give it the environment-set-and-launch script directly" ... This script is obviously platform-specific, yet still needs knowledge of the command that ExternalProject will generate to launch the sub-CMake - which the user of ExternalProject obviously does not know. I am not sure that introducing some shell-specific knowledge to ExternalProject can be avoided in this case, so hopefully it will not be a problem to do this. There are two ways I immediately think of - trying to clarify what I think you are suggesting: 1. The new <step>_ENVIRONMENT setting points to a "environment-set" script that does not try to do any launching (e.g. you could pass VCVarsAll.bat directly as the <step>_ENVIRONMENT). ExternalProject determines which shell to generate for, and generates the "environment-set-and-launch script" itself from scratch (like how I originally proposed with the "cmake -E" enhancement). In other words, ExternalProject(<snip> CONFIGURE_ENVIRONMENT $ENV{VS100COMNTOOLS}/../../VC/vcvarsall.bat x86 CMAKE_GENERATOR Ninja CMAKE_CACHE_ARGS <snip>) and away the user goes.. 2. The new <step>_ENVIRONMENT setting points to an "environment-set-and-launch" script that is expected to be configured with configure_file by ExternalProject. So e.g. the user provides a batch file that calls VCVarsAll.bat, and then there is a magical ${EXTERNAL_PROJECT_COMMAND} or whatever that the user is expected to provide at the end of the template batch file that they give to ExternalProject. I suspect this will simplify ExternalProject a little bit at the cost of more boiler-plate code that the user has to provide (e.g. can't directly call VCVarsAll.bat in the common case, must manage their own scripts). And gives the user opportunity to really mess up ExternalProject operation (e.g. forgetting to include ${EXTERNAL_PROJECT_COMMAND}, or forgetting to check ERROR_LEVEL in a shell-specific way after calling EXTERNAL_PROJECT_COMMAND, etc.). I think this would not be as user friendly, but perhaps slightly easier for ExternalProject to handle. But at the end, the configure_file substitution for ${EXTERNAL_PROJECT_COMMAND} is still potentially shell-specific.... In other words, ExternalProject(<snip> CONFIGURE_ENVIRONMENT ProjectEnvironment.bat.in CMAKE_GENERATOR Ninja CMAKE_CACHE_ARGS <snip>) And ProjectEnvironment.bat.in: @echo off call "%VS100COMNTOOLS%/../../VC/vcvarsall.bat" rem Users better not forget this next line... rem ExternalProject would configure_file this. ${EXTERNAL_PROJECT_COMMAND} rem If a user adds more commands to the end of the batch file, they'd need this: if ERRORLEVEL 1 exit /b %ERRORLEVEL% 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