BuildCodeAster

Authors:

Table of contents:

Building code_aster using waf

Building code_aster using waf

Prerequisites

code_aster needs some pre-installed components before being built.

This wiki supposes that you already installed a stable version of code_aster using the aster-full packages.

See download page.

Some words on waf

code_aster is using waf as build system, with extensions.

It does the tasks of configuration (as configure does for the autotools),
of compilation (as make does) and of installation (as a make install).

Assuming that the prerequisites have been installed by the aster-full package, you may run:

    source $ASTER_ROOT/$ASTER_VERSION/share/aster/profile_mfront.sh
    ./waf configure --use-config-dir=$ASTER_ROOT/$ASTER_VERSION/share/aster --use-config=aster_full_config \
                    --prefix=../install/std
    ./waf install -p

This is an example, please read further for more informations about the --use-config option.

ASTER_ROOT is the installation prefix chosen during installation of the aster-full package.

ASTER_VERSION is the version number: 13.4 for example.

aster-full package, since 13.4, provides an environment file for MFront (profile_mfront.sh). You must source it before running waf configure....

By default, the variant named release is built (it means compilation with
optimization for performance).
Another variant named debug is available (with debugging symbols).
To build the debug binary, just add _debug to the command name.

You can build the both variants with:

1	./waf install install_debug -p

The both variants are using the same configuration variables.

The other commands are: build, clean, uninstall (and their _debug variants).

See also the section Using several configurations.

waf manual with code_aster extensions:

1	./waf --help

Customizing the configuration

The libraries and header files are searched in standard paths by default.
The search paths can be customized using the environment variables LIBPATH
and INCLUDES. Compiler and linker options can also be changed using environment.
See waf --help for details.

Instead of defining a lot of environment variables, it is possible to store
all the parameters in a Python file that will be imported using the
--use-config option.

By default, configuration files are imported from the ./wafcfg/ directory.
You can find some examples there.

Several configuration files can be imported. See the Examples sections later.

The related --use-config-dir option defines a directory or an url that contains
the configuration files for different machines.

Here is an example of use of the configuration file created by the aster-full
package (extract from the Tutorial):

    cd $HOME/dev/codeaster/src
    ./waf configure --use-config-dir=$ASTER_ROOT/$ASTER_VERSION/share/aster --use-config=aster_full_config \
                    --prefix=../install/std
    ./waf install -p

Shell environment

If a specific environment is required for the compiler or a prerequisites,
you must source it before running waf configure.

The environment variables LD_LIBRARY_PATH, PYTHONPATH and PYTHONHOME will
be automatically exported in the code_aster environment at execution.

Installation of the testcases

The testcases are not installed by default.

You can ask their installation during waf configure (all following commands will use it)
by adding the --install-tests option.

You can also enable this option during installation:

1	./waf install --install-tests

Using several configurations

As previously explained, there are two build variants: debug and release.
They use the same configuration: the same compilation options, the same
libraries, the same installation prefix, etc.

To build a version with different compilation options, different libraries,
and/or different compilers, another configuration must be defined.
So waf configure... must be executed differently to have several configurations
in the same source tree.

To do that with waf, we use:

the --prefix=... option to define the installation directory
a configuration file with --use-config=...
the --out=... option to choose another build directory
and the environment variable WAFLOCK to not mix the different configurations.

Okay... A simpler way is to use an alias script that set the WAFLOCK
variable and pass the --out option to waf:

1
2
3

    #!/bin/bash
    suffix=`basename $0 | sed 's/^waf_//'`
    export WAFLOCK=.lock-${suffix}_build && ./waf --out=build/${suffix} $*

As you can see, the name of the script is used to define the suffix variable.
So it can be copied several times to manage several configurations.
This script must be named waf_xxx (usually waf_mpi, waf_intel...).
It already exists in the source tree and named waf_variant.

Just add a symbolic link to this script to create an alias waf_mpi:

1 2	cd $HOME/dev/codeaster/src ln -s waf_variant waf_mpi

Then, just call waf_mpi instead of waf:

1 2	./waf_mpi configure --use-config=xxxx_mpi --prefix=../install/mpi ./waf_mpi install -p

See the Tutorial to add your development versions in astk and in eficas.

Examples of configuration

Load more than one configuration file.

For example, to use the Intel compilers:

This customization is provided in the code_aster source tree, in the wafcfg
directory. Assuming you already have a configuration named computer.py
in the $HOME/mywafcfg.

To test another configuration using Intel compilers (and by keeping your standard
build), you could run:

    cd $HOME/dev/codeaster/src
    ln -s waf_variant waf_intel

    ./waf_intel configure --use-config-dir=$HOME/mywafcfg --use-config=intel,computer \
                          --prefix=../install/intel

    ./waf_intel install -p

Additional features

Running testcases

The feature has been added to quickly check a testcase.

The -n|--name option can be repeated to run several testcases. The idea is not
to replace astout in as_run but to have a very quick shortcut to check a testcase.

Example:

    $ ./waf test -n sslp114a -n ssnv15a

    Waf: Entering directory `/home/courtois/dev/codeaster/src/build/release'
    destination of output files: /tmp/runtest_pp3IwA
    running zzzz100c in 'release'
    `- output in /tmp/runtest_pp3IwA/zzzz100c.output
    `- exit 0
    running zzzz100d in 'release'
    `- output in /tmp/runtest_pp3IwA/zzzz100d.output
    `- exit 4
    Waf: Leaving directory `/home/courtois/dev/codeaster/src/build/release'
    'test' finished successfully (2.134s)

In this example, the first testcase passed with success (exit 0), the second
failed (exit 4 in red). This is the exit code of as_run.
Another possible value is nook (in red).

The testcases are run interactively (not using a batch scheduler). The results
are stored in a temporary directory.

The command waf test_debug works in the same manner using the binary installed
by waf install_debug.

More options:

--exectool=debugger: run the testcase through the debugger as configured
in astk/as_run.
--exectool=valgrind: run valgrind (or another tool) as configured
in astk/as_run.

These options are usually called with the debug variant, so with
waf test_debug.

Example:

1	waf test_debug --exectool=debugger -n sslp114a

Building old versions

waf is only available starting from versions 11.4.0/12.0.0.
To build older versions (it should be possible), bibpyt/Lecture_Cata_Ele
must be changed to a newer revision.

Resources

The waf book, section on the multiple configurations.

Wiki: Quickstart
Wiki: Tutorial

codeaster Wiki