We require MPI 2.1 anyway and nobody has reported problems.

There were still some variables with the old capitalization SUITESPARSE_
that prevented my own code from finding umfpack.h.

Thanks Dominic for the hint!

Otherwise the test could mark SuiteSparse as not found which
would break the search for other SuiteSparse libraries.

* Fix capitalization of SUITESPARSE_INCLUDE_DIRS
* Drop PATHS when searching SuiteSparse_config.h in default paths
* Add variable dereferencing in string(TOLOWER
* Set SuiteSparse_${_component}_FOUND only TRUE if actually found
* Mark more variables as advanced

According to the naming convention the variables which are
used outside must have the same capitalization as the Find*
module.
Previsously we used SUITESPARSE_*.

FindPackageHandleStandardArgs provides everthing we need.

If BLAS is not found, the whole configure process is
aborted. We actually want that BLAS is a requirement
for SuiteSparse. It is better to check using
FindPackageHandleStandardArgs.

The naming scheme is kind of broken.

Adjust code to reflect comment.

Tobias Malkmus authored 9 years ago and Christoph Grüninger committed 9 years ago

This patch adds the cmake findpackage script which locates Tim Davis' SuiteSparsae collection.

If a certain setting of the SuiteSparse library should be used it can be found using
find_package( SuiteSparse COMPONENETS <list-of-components> )
with a specific list of components.
Existence of components can be check using the SUITESPARSE_<comp>_FOUND/HAVE_SUITESPARSE_<comp> cmake variable.

The UMFPack search routines are redirected to the more general FindSuiteSparse script.

This reverts commit 8bd9ff56.

The commit did not apply the correct fix, as MPI_RANKS is not a number
but a list of ranks instead. Also, I doubt the existence of ">".

ADDTEST_MPI_RANKS is set two lines above if it has been emtpy.

It needs to be specified when using MPI_RANKS. IT otherwise
defaults to 5 minutes. No test should ever run that long, I
guess, but the default keeps automated systems from entirely
hanging up.

Set if the given test should only be compiled during `make build_tests`,
but not run during `make test`. This is useful if you compile the same
executable twice, but with different compile flags, where you want to assue that
it compiles with both sets of flags, but you already know they will produce the
same result.

It allows to specify an arbitrary command to be executed
when running the test. This may for example be used to wrap
a script around a C++ executable.

In dune-testtools we built a sphinx cmake documentation which is customized
quite a bit. With the core functionality being in dune-common, it is hard
to maintain it twice. I have therefore added some options to the dune-common
doc infrastructure, that are beneficial downstream.

You can now:
* provide custom rst sources
* provide a custom sphinx-build conf file
* limit the documentation to the current module, instead of adding all requirements automatically

The defaults of all those parameters result in an unchanged behaviour
(compared to before this commit).

As talked about on the developer meeting, a configure
switch should allow to build the tests during make all.
You can either set it through your opts file or activate
it on a per module level. If not active, you have to run

make build_tests && make test

to run the test suite.

We should always use the DUNE_ prefix for our cmake
variables, to avoid scoping clashes and to stay consistent.

Sorry for not doing this immediately, it was an oversight.

The file has been deleted in 152817d2.

It allows ctest to correctly schedule parallel tests
even though running through ctest -j.

A list of numbers may be given and the test is executed with all
those processor numbers, unless the user variable DUNE_MAX_TEST_CORES
is exceeded. In sequential builds, tests with a number higher than 1
are discarded.