Since there are a few new APIs and features, but no major changes,
it seems proper to move from 1.0 to 1.1, even though strict
backward compatibility cannot be expected.
Label bumped to 2013.10.
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.
