The HAVE_UMFPACK_WITHOUT_CHOLMOD test would generate a false success.
New test contains program with more calls to the umfpack API, reflecting
our actual usage.
This will hopefully guide some (buggy) compiler variants to not start
interpreting the header as a full program, or at least give a more
sensible error message.
Templates can now be reused across projects. The output files are still
put in the root of the output tree because that is where the client
programs will look for them.
The source code of ERT is located in a devel/ subdirectory, but it is
not usual (?) to have this structure in a separate build directory as
well. If you however build everything in the same directory as the
source code, then this sub-directory needs to be accounted for.
Using umfpack_dl_solve as a test function increases the chance that the
probe will not be able to link successfully if it has not found all
libraries necessary (to link other than trivial test programs).
These files are text files which specify which platform specific
libraries we should be looking for. We need libtool installed to
use them, but they can be generated pretty inexpensively from the
CMake script itself.
There is a convention that one can do `pkg-config --variable=includedir`
and have it return the path to the source files (even if that should
have been taken care of by options in --cflags).
If more than one match is written, then DUNE_CHECK_MODULES will return
several matches, which becomes a syntax error on the resulting command-
line. Thus, check if there is a match before writing anything.
Dunecontrol scans the module directory for certain files and phrases
which must be present if the project can be used as a dependency for
other DUNE modules.
The old implementation erraneously used only the first argument that was
passed to the testing procedure due to the way lists are passed in CMake
when unquoted. Thus, the test failed for SuiteSparse >= 4.0 which needs
more than one dependency.
Also add dependency to BLAS and LAPACK which was hidden because the
caller already included these itself.
Previous implementation had a separate search path for headers and for
the library, which in the case of "RedHat-multiarch" made it miss the
library (it was looking for /usr/lib/lib64 instead of /usr/lib64); the
new version starts looking from /usr.
UMFPACK is by default dependent on CHOLMOD, but on some systems it is
compiled with -DNCHOLMOD; in those cases we should not try to link in
the library -- it may not be available and in any cases it is not used,
so it is just a superfluous dependency.
The way the test was written earlier, it would accept if it found
components that were transitively pulled in even if the originally
requested component was not!
At this time no probe is added to check if an UMFPACK without dependency
to CHOLMOD is installed; thus if you need/want UMFPACK, you'll have to
go for the entire SparseSuite.
dunecontrol will read the dune.module file first, before calling any
configuration files; thus it cannot be initialized from the script
but the version numbers must be hardcoded here and updated manually.
Note that using pkg-config is NOT recommended because of:
1. It doesn't know which language you are using, so language-specific
options such as -std=c++11 or -std=c99 cannot be passed along. Yet,
the build will corrupt if you don't get these correct.
2. It has no means of communicating which defines that should be set
in config.h, effectively disabling them all, possibly leading to
inconsistencies between the library and the executable.
On Linux all libraries that are specified on the command-line will be
referred to in the resulting binary. There may be find modules which
just adds everything to satisfy every possible dependency; we want to
discard those unnecessary libraries.
CMake will raise an error if you try to remove something from an
unset variable (whereas removing something from an empty list "" is
fine). If the user doesn't have the appropriate library, the search
will turn out empty, and the configuration will fail with a syntax
error instead of a message that the library is not found.
This CMake module will set up a target for compiling a set of headers
which can then be added to compilation modules to speed up compilation.
A separate target is created because the function doesn't know all the
sources of a target, and to reuse the precompiled header across several
targets that share the same characteristics (such as unit tests).
BLAS module originally required Fortran to be enabled, newer module
doesn't; LAPACK module had some spelling errors that prevented it
from working; and cmake_push_check_state() is not available before
2.8.6.
Debian object code libraries are in directories which include the
platform name to allow several of these to co-exist. Other distros
such as Fedora uses a simpler naming scheme (e.g. "lib64/") which
is more backward-compatible.
Use the _ROOT suffix to direct the CMake module to use a particular path
to the SuiteSparse installation without also triggering config mode (by
convention CMake uses Foo_DIR as the name of the variable which
specifies where to look for another *project*).
Infer the type of library from the target and only activate debug symbol
stripping if it is an executable format. Note that this changes the
signature of the strip_debug_symbols macro.
Although ERT is built with CMake, it does not yet provide a config-mode
module in its build directory. This also means that the find module must
be pointed to an installation, not a build directory.
If one sets the variable foo_DIR it will cause CMake to look for a
configuration file in that directory. In case we want to set the root
directory to an installation which doesn't have a config-mode CMake
module, and use the find module provided by ourself, we need a separate
variable that can hold the location of this directory and the most
common suffix for this seems to be _ROOT (an alternative is _PREFIX)
If the path to Notay's AGMG library is provided through the cache
variable AGMG_ROOT, then include this in the build and enable the
test.
It would have been desirable to use the variable name AGMG_DIR for
consistency with the other modules, but unfortunately this name
will alter the functionality of CMake's find_package.
