GitLab

Codes using the popular Autotools/Autoconf ecosystem expect users to compile code by something like

wget http://example.com/code.tar.gz && unpack || git clone ...
./configure --with-MPI --with-TBB --without-lapack
make

Configure does several things, but typically it

• Checks whether the neccessary compilers and libraries are installed by doing test compilations and executions
• Generates a Makefile

We probably all dislike configure for doing these lengthy tests which always consume time.

In similarity to configure, some ExaHyPE users (notably Dominic) interpret the ExaHyPE toolkit as a configure step:

wget http://exahype.eu/obtain/exahype.tar.gz ...
./toolkit.sh PathToSpecfile.exahype
make

We know this analogy at least does not hold because some build decisions are made at making time, for instance the choice for MPI, TBB and Assertions. Our toolkit never executes any compiler, it only generates code. There is a clean distinction.

However, frequently compilation fails and users must find out why. What a real configure step would provide is a check for compiler capabilities. With tough problems, users have to debug these capabilities anyway, for instance by compiling and running my compiler challanges.

I suggest we add an option --test to the Toolkit which brings in some configure flavour. When enabled, after the invocation of the regular Toolkit it could compile and run some tests and test for

• A valid C++11 and Fortran (long lines + REAL=8 bytes) compiler (test programs)
• Presence of a modern and working TBB (test program)
• Presence of a working MPI (test program)

Of course, running these tests probably requires to have some flags such as EXAHYPE_CC already set.

As an alternative, I suggest we have another Makefile target for our make system: make test, which does not compile the code but instead compiles (and runs) these tests.