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 should be passed the option
--configure-opts="--enable-fieldvector-size-is-method" if you want to
rebuild it from scratch without bazillion strange deprecation warnings,
this flag allows us to participate in that dance.
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.
If the installation prefix is set to /usr, then it is assumed that the
user has write access to the entire of that subtree, and that it would
be advantageous to put the .debug files in the /usr/lib/debug directory.
This is the usual case for package installations.
On the other hand, if the prefix is NOT /usr, then it is probably a
local installation; someone trying to install it to a more restricted
area. In that case, the default is to follow the binary, so that GDB
will still pick up the .debug file when loading the shared object.
In any case can this default be overridden, should it turn out that the
configuration script has guessed wrongly for your needs.
The test started failing in commit 7d7f62e, but this was not detected
due to no automatic test environment. The commit changed the cell
numbering from "per-column (K,I,J)-ordering" to "per-plane
(I,J,K)-ordering". Consequently, the "correct_answer" seized to be
correct.
This change restores the "correct_answer" in the ordering introduced by
commit 7d7f62e.
While here, adjust style of the DisjointColumn test case for legibility.
The datafiles that are in the tests/ directory are copied to a
corresponding location in the output tree, and the tests are then
executed from this directory (i.e. their current directory is set
to tests/.
If a test overwrites an input file, this will not be noticed in the
source tree -- but don't do that! The tests have write access to
their current directory, so they can generate new files and compare
them to a stored master file.
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.
Newcomers may want to step through the tutorials in the debugger without
creating a new project specifically for them; this enables them to do so
through the regular build system.
To see how a program is linked with the library, just execute
make tutorials VERBOSE=1
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.
Some versions of the compiler are buggy, and will actually crash if
precompiled headers are used. This option enable disabling the feature
and building without by simply setting a command-line option.
Configure everything using CMake and run 'ctest -D Experimental'
inside the build directory. If you want to participate in the nightly
testing, add
#!/bin/sh
cd $BUILD_DIR
exec ctest -D Nightly
to /etc/cron.daily/opm-core. The results can then be browsed at
<http://opm-project.org/CDash/index.php?project=opm-core>
The name of the test is taken from the stem of the file; if two tests
have the same name in different directories, the makefiles will get
confused, so don't do that.
People are encouraged to convert the tests in not-unit/ to proper unit
tests and move them back into the parent tests/ directory; they will
then be picked up by the testing framework automatically.
Every program that relies on manual inspection has been moved to a new
(hopefully short-lived) directory called not-unit/; every remaining
file has been given the prefix test_ to indicate that this is the
executable test to be run.
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 --prefix= in ./configure to enter the directory under which the
files should be installed on the target system, use DESTDIR= in
make install to redirect files to another location when building.
On an average system this will cut around 15% of the total build time.
Unfortunately, including Boost headers in the precompiled header takes
longer time to generate and then read in each module, than just
including the necessary headers in each module.
Use Noel Llopis' list_precomp.py at
http://www.gamesfromwithin.com/wp-content/uploads/bin/list_precomp_py.txt
to analyse which headers are included the most and are candidates for
inclusion.
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).
We do dependency management the right way; there should be no need to
use ccache on top of this. Actually, it will just hurt performance to
do so without any win.
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.
