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.

Old feature support macros which were tested until 2.4, kept around
for one more release. As these are now always supported due to the
new compiler requirements, they are directly defined without an
explicit test.

We aim to document the entire relevant user API. Some functions
from CMake are not worth wrapping, so we need to add them to our
documentation.

Broken/missing references, wrong directives etc.

These commits broke compiling / linking if one package was found
but the includes / libraries were not added. We need a different
approach to hide the ENABLE_* trick from the user and keep full
testing capabilities.
This reverts commits 0f12caff
and d75c3a46.

We do not want one such documentation per module, but instead
we would allow people to use it from their module and get a
documentation generated from all the dependent modules. This
needs some changes to the machine.

This includes the following workflow:

* The cmake module path is globbed for any modules matching *.cmake
* The opening comment is parsed for the following rst directives:
  cmake_function, cmake_module, cmake_variables
* From those, a browsable documentation is generated.

To run properly, a python interpreter and sphinx are needed.