[cmake-developers] Setting up environment using ExternalProject_Add

[Brad King]

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.

> Users would be required to provide scripts for environment setup in the
> format of the native shell

For this projects would need to spell out platform-specific code anyway
so there is no point in trying to abstract that part away.

> 3. Then CMake runs the above script as normal and checks the exit code

I don't think CMake actually has to be in the middle here.  The generated
build system could reference the script directly.

> 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

Therefore I do not think add_custom_command needs any hook for this.
One would simply give the script as the COMMAND.

> 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).

Thanks,
-Brad