[CMake] execute a script before and after configuration

[Dominik Szczerba]

I now see your point about changed env, sorry, I misunderstood you before.

Indeed module load/unload changes the env, but the changes are
excessive, involving include and linking paths for the currently
loaded compilers (and there can be a few...) and many other switches
involving paths to packages with explicit versions. It will be very
difficult - and very unsafe - to write - and maintain! - a solution
basically replicating the complexity that "module load/unload" hides.
I hope there is some way to run cmake as a shell process or to somehow
make some use of cross-compiling. Unfortunately, I do not know how,
and I do not know any other poor guy whose complex software platform
must build and run on both Windows and Cray to ask advice ;)

Regarding testing functionality, I think a better workaround than an
external project is simply two builds, one for the scheduler and one
for the local testing. It's still annoying and time consuming for a
big project, but I can live with that for the  moment - unlike try_run
unfortunately. One workaround for it that I possibly see is to
delegate all try_run tests to python scripts. The problems here are
that python is not always available on all platforms, and that in some
cases it is not easy to do, e.g. when testing FPU accuracy.

Regards,
Dominik

On Sat, Jan 21, 2012 at 8:11 PM, Eric Noulard <eric.noulard at gmail.com> wrote:
> 2012/1/21 Dominik Szczerba <dominik at itis.ethz.ch>:
>>> Running something from the command line does not mean it doesn't change the
>>> environment.
>>>
>>> Would you try
>>>
>>> $ env > env1.txt
>>> $ module unload sysmodule_you_dont_want
>>> $ env > env2.txt
>>> $ cmake -E compare_files env1.txt env2.txt
>>>
>>> I'd be surprise if nothing changed but I may be wrong.
>>
>> You are of course right, but this is not the scenario here. If you put
>> "module un/load XXX" into a bash script, and call it from command
>> line, it will only modify the env for this script/process. On the
>> return your original env will not be changed.
>
> The very same scenario is happening with CMake.
>
>> To change it,  you need
>> to "source" your script, but that is what seems to do nothing with
>> cmake.
>
> Yes that's precisely the point CMake is not behaving like a shell at ALL
> with respect to env var.
>
> Re-read my other message.
>
> When cmake executes a command (using e.g. execute_process)
> it "forks" that is a NEW process which is a child of current cmake process
> is created, then the command/executable is run within the child
> (or replace the child http://en.wikipedia.org/wiki/Fork-exec)
> then the child terminates and CMake continue with other
> command with may be other child process.
>
> So when you "COMMAND module unload blah" this only
> affect the current child.
>
> That's the same difference between "sourcing" a script and "running it"
> with CMake you have no way to "source a shell script" because CMake
> is not the shell.
>
> From within CMake you "source" a cmake script (just include it)
> but not a shell script (which seems to be the machinery behind the
> 'module' command).
>
> What you can do however is to identify which environment change did the
> module unload do and then do the same with cmake.
>
> You may be able to monitor the change from cmake using a shell script
> which does:
>
> env > file1
> module unload
> env > file2
> diff file1 file2
>
> --> then process the diff ouput with some cmake script
> en reproduce the environnement change using
> set(ENV{EnvVarName} "newValue")
> --
> Erk
> Membre de l'April - « promouvoir et défendre le logiciel libre » -
> http://www.april.org
>