[CMake] execute a script before and after configuration

Eric Noulard eric.noulard at gmail.com
Sat Jan 21 07:35:07 EST 2012


2012/1/21 Dominik Szczerba <dominik at itis.ethz.ch>:
>
>> May be Dominik can explain this
>> "so that some small test programs are allowed to run without
>> scheduler"
>> a little more?
>
> Simplest example, suppose I need to compute epsilon and save it in
> myconfig.h. To this end I need to run a small program and I use
> TRY_RUN for that. But by default you are not allowed to run any
> programs on the login node, all compiled execs must go through a
> scheduler. This is not what I want for a test program. To allow it to
> run on a login node during cmake configuration I must first unload a
> certain module, so it is compiled differently to run directly on the
> calling machine. But right before the actual build of my application
> starts it must be loaded again, else I would not be able to submit my
> job with the scheduler because it would be compiled in run-locally
> node, which is not what I want for my application.

This looks like kind of cross-compiling problem.
see cmake --help-command try_run.

In your case, the host being the login/frontend node while the target
is the parallel nodes.
The "only" difference here is that the compiler switch is probably hidden by
the "module" call.

May be that if you can wrap "all your small tests" to be tried-run on
the login node
in a separate project you can
execute_process(COMMAND your-shell-script.sh ${CMAKE_SOURCE_DIR}/path/you/want
                          OUTPUT_VARIABLE TO_BE_PROCESSED)

the "your-shell-script.sh" would do something like:

module unload systemmod
cmake --build $1
cmake -P /path/to/your/separate/project/collect_result.cmake

after that you get the result oif the test done with the
"systemmod" unloaded in TO_BE_PROCESSED.

Others may correct me if I'm wrong but each command is processed by
a forked child so that any modification (w.r.t. the environment) in the child
is lost in the parent process and the following other COMMAND  if any.

Thus you should really do it by hand or wrap-up a separate project which will
do the testing.

Note that this "helper project" may enable you install
some helper executable (compiled for the login-node execution)
inside the build tree of the to-be-configured project such that
you can actually run those executable during the configure process
of the main project.
You may be able to achieve that [more] easily using "ExternalProject_Add"
see
cmake --help-module ExternalProject

By the way you may not be the only person to use CMake on Cray machine
how do the others do?
Do they use some try_run as well?

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org


More information about the CMake mailing list