If the user has given a path to the module, then the system paths should
not be searched, as these may contain an old and outdated version. We
don't necessarily want that just because there was a problem with our
own installation!
If we are on a 64-bits machine, there is no point in searching lib32
and conversely. Quite the opposite, it can only end badly if a library
is actually found in the wrong architecture directory.
If libumfpack.so does not declare an explicit dependency on libamd.so,
the linker option -Wl,--as-needed will cause an undefined reference
since we don't use libamd.so ourself. If the configuration determines
that this may be the case, a linker option that forces linking the the
AMD library is added for the SuiteSparse library, and the general
configuration then gets out of the way if this is set.
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.
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).
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.
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.
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*).
Search for modules in this library in the same style as Boost; by
specifying a list of components. If all on the list is present, then
a list of libraries to link with, is returned.
