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.
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.
CMake will change to the source directory when processing the
CMakeLists.txt file which causes relative paths to be based on this
instead of at the build directory which is probably assumed by the
user.
Instead of having to run `ccmake` or looking up which variables that
must be set, the configure driver is now enhanced to recognize options
that sets the installation directories for some of the dependencies.
Although ERT is built with CMake, it does not yet provide a config-mode
module in its build directory. This also means that the find module must
be pointed to an installation, not a build directory.
If one sets the variable foo_DIR it will cause CMake to look for a
configuration file in that directory. In case we want to set the root
directory to an installation which doesn't have a config-mode CMake
module, and use the find module provided by ourself, we need a separate
variable that can hold the location of this directory and the most
common suffix for this seems to be _ROOT (an alternative is _PREFIX)
QtCreator stores a file containing amongst other things the path to where
your build tree is and what parameters you used for the configuration
process. These data is user-specific and should not be stored in version
control.
If you open the project in QtCreator again after having made changes
to CMakeLists.txt outside of it, it may create a new user file which
should be ignored just like the original.
We call the Make utility passing the right number of cores to do
efficient parallel compilation. The command to do this is simple,
but laborious to type every time. Add one to the number of nodes
to keep the CPU busy while one is waiting for I/O.
Put the entire compilation at a lower priority, both CPU and I/O-
wise. This way we don't kill the computer and the user can continue
working with other interactive tasks. If there are no other jobs,
then it will complete as before.
By having a front-end for the compilation, we can later switch to
the Ninja generator without disturbing the workflow.
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.
CMake has a similar set of macros to FC_FUNC, but they of course use
another name. It also blatantly writes these macros to its own file,
overwriting anything else there (!).
This wrapper provides the same FC_FUNC interface as Autotools would
do, thus requiring no source changes.
CMake files are in general not portable between systems anyway, so we
may as well take full advantage of the native instruction set.
There must be a companion option to switch this off in case anyone
wants to build a package for distribution.
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.
This script enables the use of `configure && make && make install` for
those users who have this combination ingrained in their fingers or are
too busy to read the manual.
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.
Allow arguments to be used on the list of dependencies, this facilitates
searching for things like e.g. Boost, and there is now only need for one
list since REQUIRED can be one of the arguments.
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.
If the library is not found, we will now get a message that the test
program failed to link because of a missing symbol, instead of an error
message from CMake that we tried to add -NOTFOUND libraries.
