The list of tutorial programs were filtered on whether UMFPACK was
located or not, but then the list was reset to the original again
just before compilation starts.
Also corrected a minor spelling error which caused a similar error.
The collections have been checked for equal size, we then only need the
size of one of them to iterate. The other boundary pointer is never used
and only generate needless compiler warnings that pollutes the output.
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.
