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.
`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)
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.
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.
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.
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`
Default is still to make a shared object because this is the most
versatile target (it can be included in other shared objects as well
as executables).
Note that due to limitations in CMake, either a shared or a static
library can be built, but not both. (This is due to the fact that on
Windows, an import library has the same name as a static library).
Infer the type of library from the target and only activate debug symbol
stripping if it is an executable format. Note that this changes the
signature of the strip_debug_symbols macro.
If the path to Notay's AGMG library is provided through the cache
variable AGMG_ROOT, then include this in the build and enable the
test.
It would have been desirable to use the variable name AGMG_DIR for
consistency with the other modules, but unfortunately this name
will alter the functionality of CMake's find_package.
Although this amounts to some double work, it doesn't make the
configuration noticeably slower, and it ensures that the lists are
always cleaned up (in a proper way).
Similar to the -std=c++0x flag for C++ code, we probe for, and add if
available, -std=c99 for C code, since the compiler may generate
different initialization code for this variant.
The reporting from the bundled CMake modules is not as polished as for
probing for C++ flags, but not bad enough to warrant rewriting the code
from scratch just to fix the output.
find_package only searches for FindXxx-modules in the path specified by
CMAKE_MODULE_PATH; other paths are supposed to contain config-mode
modules (much like pkgconfig).
Generate the config-mode module in the installation directory using the
same template as is used for the one in the build directory, only
selectively swapping some directories in the relevant variables.
If we don't have a C++11 compiler, we won't be able to build DUNE, but
opm-core is still usable with for instance UMFPACK. However, if it *is*
available, it should be used to improve the ABI compatibility with other
parts of the suite.
Put everything the user needs to link to the opm-core library into the
config-mode file, including result of probes. If this conflicts with
other packages, that is a configuration issue that must be resolved
anyway.
The advantage of doing it like this is that the user can build against
the library without knowing how it was configured; the only thing that
must be provided is the path to the config-mode module!
We need the list of variables to put in config.h for the CMake config-
mode module; reuse the code that writes the list to config.h in the
first place to also write CMake-compatible lines.
This makes it easier to write this list to the config-mode module and
let it merge with those from dependencies in the user's program
(although that implies that we no longer pretend that inconsistencies
are not possible).
The convention that singular form contains values for this project
alone whereas plural form contains values for both this project and
dependencies, is used.
Modules that starts with the prefix "Use" alters the build to enable
something by default, whereas modules that only provide functionality
is not common to start with that prefix.
Some older packages, and notably those that are detected by PkgConfig,
only give library names and then a list of library search directories.
Add to link_directories here in order to support this configuration,
even though it is deprecated in newer versions of CMake.
Users should be able to point their opm-core_DIR to the build tree of
this project and have their client programs pick up all the necessary
settings to use the library. The config mode file helps to bridge
variables from one build (of opm-core) to another (of client program).
In this stage of development it is assumed that having a build that is
easy to debug from within an IDE has the most value for most users.
If any speed comparisons are to be done, be sure to configure with
-DCMAKE_BUILD_TYPE=Release
