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.
These tend to be backup files (on the form .#*#), and anyway CMake will
later consider them to not have a proper filename stem (everything is
part of the extension), leading to all sorts of strange errors.
CMake will not be able to make sense out of the YYYY.MM versioning
convention (since the "major" versions are not related), and we
expect API breakage in the short term anyway.
If we are building in a VM which doesn't have /proc mounted, then it is
most likely that this is done on a shared server; we revert to building
for a single processor.
Since the data files are generated by the tutorials, it is natural to
have the figure generation program also together with this source code;
otherwise people may think that it have to be used for *all* figures
These changes make it easier to call the program from a generated
Makefile rule, since only the Makefile knows where the output tree
is (containing the rest of the documentation).
`make check` is run by the Debian package creator, so it must be a
supported target in the Makefile. For now this is just the same as
`make tests`, but in the future we may/should/must expand this to
also run the tests and figure out if the output is OK (whereas
`make tests` will continue to only compile them)
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.
Version numbers for the library follow ABI-style and is independent
of the ones for releases. If the interface breaks, we change the
soversion, regardless of the timing of the releases.
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*).
It is very annoying having to build all the tests when you are
testing some code in the main library. Someone downloading the
library probably doesn't need the tests either, so these are left
out of the default target.
By using --disable-debug (--enable-debug is the default), release mode
can be toggled from the wrapper script.
Some IDEs, notably QtCreator requires this flag to be set when running
CMake, in order to enable debugging properly. Thus, it is explicitly
set (and printed) when using ./configure also.
dunecontrol will look for a file called dune.module and use the
information therein to determine which and in what sequences directories
should be built.
By specifying dune-common and dune-istl as dependencies here, we
ensure that those directories are available before opm-core. They are
not true dependencies; opm-core is usable without them, but if you are
using dunecontrol, then it is a good bet that dune-istl also is
available and desirable to use.
