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.
Having option checking catches typos. Disabling the checking enable us
to use the same build options for a bunch of packages even though they
may not have the same dependencies.
Since the project is only building one main target, the library, and
the other targets are just auxiliaries, then the distinction becomes
confusing and unnecessary.
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.
The -j flag should only be submitted once. If we are enclosed by yet
another layer of makes, then it will have setup everything for this
sub-make to take part in the job pool.
If you run make with -n switch, it would just print the forwarding
command. Now it should continue into the original make, having that
one printing its actions as well.
The Doxyfile is still in the root directory because this is more like
a configuration file, and also its presence will be a cue to some
users that Doxygen is possible to run on the project.
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 directory must be specified with full path to refer to the source
directory. The images will not be referred to by this path, but rather
copied to the output directory (as of Doxygen 1.7.6.1 at least), unlike
the stylesheet (consistency is so last decade).
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.
Static libraries usually holds the debug information together with the
library because they are not loaded directly (but linked together to an
executable, which can be stripped)
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.
