The previous version assumed that we had libraries, and thus always
installs the .pc file in the multi-arch library directory. However,
we now have modules which does not have a library, but whose header
files still need to be located. Since the lib/ directory is usually
in the pkgconfig search path, it is natural to put them there.
If the option USE_VERSIONED_DIR is set to ON (default is OFF), then
most files are installed in a ${suite}-${label}/ subdirectory
(e.g. header files go in "/usr/include/opm-2013.03/"). This enables
us to easily install backports of newer versions on systems which
have a system package for an older one, without getting conflicts.
By using a separate variable for this we can easily grep for where
the build system depends on its own location, and also change the
policy regarding this later.
Note that there is no opm-macros module; this is a "psuedo"-module
which links to an additional one (currently, the one we're in)
When passing libraries to gcc/ld, the search path and library name must
be specified separately. This is already done when writing a libtool .la
and should be done in the pkg-config .pc file too.
Templates can now be reused across projects. The output files are still
put in the root of the output tree because that is where the client
programs will look for them.
There is a convention that one can do `pkg-config --variable=includedir`
and have it return the path to the source files (even if that should
have been taken care of by options in --cflags).
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.
Note that using pkg-config is NOT recommended because of:
1. It doesn't know which language you are using, so language-specific
options such as -std=c++11 or -std=c99 cannot be passed along. Yet,
the build will corrupt if you don't get these correct.
2. It has no means of communicating which defines that should be set
in config.h, effectively disabling them all, possibly leading to
inconsistencies between the library and the executable.
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.
