The difference between the version number (1.0) and the label (2013.03)
is: The version is time-independent but shows the level of compatibility,
see e.g. <http://www.semver.org>, whereas the label is a marketing tool
which describes the project progress.
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.
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.
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.
This allows projects which use the DUNE build system and want to use
OPM-Core to specify a dependency in their dune.module file. (i.e. they
don't have to worry about compiler and linker flags anymore.)
opm-core can still be used without having DUNE installed, though. This
means that for users which do not need/want a dependency on DUNE,
nothing changes.
v2: avoid naming conflict of the AX_BOOST_BASE macro with dune-common
by renaming it to OPM_BOOST_BASE.
v3: make the library detection work nicely
v4: Use AX_BOOST_BASE M4 macro from opm-core instead from dune-common
as base for OPM_BOOST_BASE to get rid of a few bugs, reworded
commit message. Thanks to Bård Skaflestad for the review.
Roland Kaufmann
Andreas Lauser