[cmake-developers] Setting up environment using ExternalProject_Add

[David Cole]

One thing to consider before embarking on modifying CMake for
"required environment" purposes is that it might be just as simple to
"force" (or at least strongly encourage) your project developers to
use the proper environment for running the whole build.

You could, for example, have an initial "external" project which all
others depend on which verifies the proper environment is set when it
is called. If not, it fails with an error, and prevents downstream
bits from building.

Such a project would have to *always* be called, whenever *any* build
step is executed, but if all it does is verify proper environment
settings, it should not slow your build down at all.

I have such a project I'm working on, and it works fairly well. If you
run it outside the expected env, it fails quickly with an informative
error, explaining how to run it in the proper env. Unfortunately, it's
private, so I can't share a link to it, but the idea is a sound
approach, without any complicating changes to CMake.


HTH,
David C.



On Wed, Aug 12, 2015 at 10:10 AM, Brad King <brad.king at kitware.com> wrote:
> 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
>
> --
>
> 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