GitLab

Now they just cluttered the main build directory, put them also in
private_modules/. This of course assumes that no two test programs
define modules with the same name.

Also, this necessitates that the shared sources are also only compiled
once, thus I put them into an internal libtool convenience library and
link all test programs with it.

Remove all references to private functions and symbols from the public
Fortran modules. Install also only the public modules

If compiled with MPI, the necessary "mpiexec -n 2" was not written
in the check scripts. This commit is based on a patch provided by
Michael Banck from debian.org

Now they just cluttered the main build directory, put them also in
private_modules/. This of course assumes that no two test programs
define modules with the same name.

Also, this necessitates that the shared sources are also only compiled
once, thus I put them into an internal libtool convenience library and
link all test programs with it.

Remove all references to private functions and symbols from the public
Fortran modules. Install also only the public modules

The QR decomposition test program can now called with parameters for
matrix size, nev, and block size.
This closses issue #20

Michael Bankd (debian) provided a patch, which allows
to run the qr-decomposition test programs with smaller matrices, and
thus allows testing in reasonable time on limited hardware (e.g. arm
devices)

In order to make the patch work, also Makefile.am was updated

Some of the file names were too long, automake then dropped these
files when doing "make distcheck"

Now this is done consistently both in autoconf and automake. One can now
safely call make clean and the header files are re-generated
automatically.

Automake does not easily allow to use the same source in a libtool
library and in a program

The issue why these test programs are simply not build
has to be investigated

It turned out that if a CPU supports SSE the already existing
test for SSE assembly instructions always passes.
However, the compilation of gcc SSE intrinic instructions might
nevertheless fail if gcc is not called with one of the options
"-msse3", "-msse4" , "-msse4.1", "-msse4.2", "-mavx", or "-mavx2"!

Obviously gcc does still not consider SSE as a standard on X86_64
Intel CPUs.

An additional configure test has been introduced, which test for
gcc intrinsic sse instructions. If this test fails, the corresponding
kernels are switched off.

The C++ kernels can be written as C kernels, which simplifies the build
procedure

In order to increase type safty all ELPA2 kernels provide now
an interface. The interfaces for the C/C++ kernels are automatically
generated during the configure step

The test programs are just needed at the build step (make check),
they are useless for users and will not be installed anymore