This patch gets rid of the compiler warnings generated by the antiquated ARPACK sources by turning
the ARPACK include directory into a system include directories. Compilers don't generate warnings
for code in system include directories, so this is a blanket solution for all kinds of problems in
this source (that we treat as upstream and thus can't fix anyway).

depending on a preprocessor define we switch the base classes to be
pure virtual, or implement a dummy category(). If the classes are pure
virtual the old interface with an enum is not possible anymore.

To enable/disable the backwards compatibility check we provide a cmake
flag DUNE_ISTL_SUPPORT_OLD_CATEGORY_INTERFACE, which defaults to 1
(e.g. backwards compatibility enabled).

Markus Blatt authored 8 years ago and Christoph Grüninger committed 8 years ago

Previously, we only supported one numeric type (float, double, complex<float>,
or complex<double>) that the user could select via a cryptic preprocessor
define. This was done this way because when including SuperLU headers we
would otherwise have multiply defined structs in SuperLU. At least in 4.3
GlobalLU_t is defined in slu_sdefs.h, slu_ddefs.h, slu_cdefs.h, and
slu_zdefs.h

With this commit we do not include the problematic SuperLU headers anymore.
Instead why define the functions called by us with extern C within DUNE.
In addition we now provide all the numeric types for which SuperLU drivers are
found at the same time.

Hopefully this will also fix problems with multiply defined BLAS routines experienced
with arpack and SuperLU.

Previously CMake pretended to have found a valid
SuperLU version for DUNE even if the version was
too old (i.e. < 4). People having such an old versions
only noticed this via later compile errors of binaries
using SuperLU. That is far too late.

With this patch we introduce a compile check into the
CMake module that fails for old unsupported versions.
In that case CMake will not find SuperLU.

* Use correct macro
* adjust changes for other types then double, too

Arne Morten Kvarving authored 8 years ago and Christoph Grüninger committed 8 years ago

API for solver routine changed. Since there is no versioning
in SuperLU we have to do a probe to detect the new library.

Don't end configure if BLAS is not found. Only the SuperLU
test should fail, which will be the case anyway.

Use proper C macros for LDL and SPQR.

Let FindPackageHandleStandardArgs handle missing dependencies.
Mark ARPACKPP_LIBRARY as advanced.
Remove dead code.

It's confusing and against our style-guide.

The arpack++ package from Debian comes with a shared library that we
have to link to. Otherwise the linker will complain about missing
symbols when we try to build arpackpptest.
As there seem to be other versions of arpack++ that are header-only, we
only link to the shared library if it was found.

The commit 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 commit 27613560.

Boost is no longer needed in dune-istl.

The new modules from the arpack feature branch were
never installed and this would have broken installed dune-istl
modules.

With this commit they now are installed for both CMAke and autotools.

Check for the ARPACK++ library (needed for the new Dune::ArPackPlusPlus_Algorithms class template)

on fedora 21, the default subdirectory for SuperLU includes is
called "SuperLU".

The check gets removed from dune-common, thus ISTL has to call it itself.

This reverts commit 901b5954.
It (METIS) does not seem needed for compilation and the patch
forced the user and downstream modules to add additional compile
 and linker flags.

Just like for the autotools.