GitLab

This makes elpa.spec the single point of reference for the version
number, otherwise care would have to been taken to set it in both places

Apparently, when prepending $(FCLIBS) to $(LINK), the resulting command
line has the $(FCLIBS) libraries then _in front_ of the object files,
which some linkers do not like (error adding symbols: DSO missing from
command line)

Recent autoconf has complained about the lack of this

Just call autogen.sh in the spec file if configure does not exist

It should be enough to just require the -devel packages, RPM is smart
enough to automatically include the run-time library dependencies. On
SLES-11 SP4 apparently one could not both require blas and blas-devel
without a conflict, whatever the reason for that might be...

These functions were made private with ELPA releases 2016.05.001
and 2016.05.002, but they should be public

Only one .info file can be "packaged" at a time, so do it that way.
This should fix the spontaneous "total_coverage" build failures.

The aligmnent for all needed values can only be done with 16 bytes
(i.e. SSE)

This closes issue #24

A small missing '$' caused a lot of mischief. Augmented also the tests
to detect something like this in the future

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

This allows to install several versions of the library in the same
directory

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

The optional build via "--enable-assumed-size-arrays" is also
tested in the CI

Using Fortran assumed size arrays makes debugging a lot harder,
thus as default these are not used in ELPA.
However, it might be, that some compilers make unwanted copies
if calling subroutines with array slices. Then switching back
to assumed size arrays might create a performance gain