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.
Old implementation had a problem with the special case that you
specified a directory directly under the root (e.g. /usr); dirname
adds a trailing slash in that case.
Since this is a compatibility script it will probably benefit people
seeing which underlaying CMake command is being executed (not at least
for debugging purposes)
If you are building in-tree (which is commonly done by dunecontrol),
it can be advantageous to have a target which is capable of cleaning
out all the files that CMake left without having to erase the entire
folder.
Path to DUNE libraries are specified with the ROOT prefix, but with the
stem with the same name as the module -- in lowercase (otherwise; does
the hyphen uppercase to underscore?). This deviates somewhat from the
usual CMake convention of using uppercase all over the place.
When creating CMake files for config mode, a separate version file is
generated; this should be on the ignore list as well if we are going
to build in-tree.
If we are building in-source, we don't want to have a bunch of output
files in the root directory; instead we put them in CMakeFiles/ where
all the rest of the object files go.
If `make install` is run, the document is included if and only if
it has already been built. If `make install-html` is run, then the
documentation is always generated first, before installation. To
build the documentation separately from installation use `make doc`
The volume of warnings generated for the documentation completely drowns
out anything else useful. Until we have fixed more of the comments, this
should be disabled as to focus on problems with the code instead.
