dunecontrol is capable of doing out of source builds, that are
not nested within the source directory by giving an absolute path
to the --builddir option. Unfortuantely, this (nice) feature was
not documented.

sadly the touchpad added some arbitrary "pwd; ", which slipped my
test, as I don't use cmake. Thanks to Andi Buhr for pointing this out.

up to now you could specify a BUILDDIR variable, which implied that modules were built in
$srdir/$BUILDDIR.
Imagine you have your dune modules in $HOME/Src. When you set BUILDDIR=build.g++
your dune-common module is built in $HOME/Src/dune-common/build.g++
Now you change BUILDDIR to an absolute path, e.g. BUILDDIR=$HOME/Build.g++
With the latest change dunecontrol will now build dune-common in
$HOME/Build.g++/dune-common/

Thanks to Angar for bugging me :-)

Bård Skaflestad authored 11 years ago and Christoph Grüninger committed 11 years ago

This commit implements support for using nested build directories of
the form

    (o) build/sequential/debug/cmake/clang
    (o) build/parallel/release/autotools/gcc

in addition to the separate build directory feature that already
existed.  This enables confining multiple build configurations to a
single subdirectory of each module's directory to avoid otherwise
littering the module directory.

Note: Using "mkdir -p" presumes a SUS v3 mkdir(1) utility.

The dune symlink was deprecated since 2009.

This completes the last patch by using $m for the module name. Finally,
installed modules are found correctly.

The check was whether $module_inst is yes, but what we actually want to check
is $INT_$module. This patch fixes this and forces configure to use pkg-config
for the installed module again. Only this allows us to extract custom libdirs.

clang does not support -print-multiarch. Therefore we try to
extract the "Target:" line from clang -v.

This patch moves the "set +e" command to the correct location during
detection of the multiarch variable. That is is before any
$CXX --print-multiarch call. Now dunecontrol will not fail for compilers
not supporting it.

It is the default any way and people might want to change it via an opts-file.

This patch fixes two issues:
- Faulty an non-posix sed expression
- Precendence issue (multiarch was extracted before compiler was set.)

Somewhere along the many changes we stopped forcing usage of pkg-config when
testing for installed versions of modules during configure. Without using
pkg-config there is no way of detecting custom installation parts used by
the user. In my case, this broke finding modules installed via cmake from
modules that are to built with autotools.

This patch forces DUNE_CHECK_MODULE to use pkg-config to setup the paths for
installed modules by dunecontrol not provinding --with-module=<path> to configure
for installed modules.

Previously some of the pathes (e.g the multiarch ones) took precedence
over the others. But as with same some of the pkgconfig files are installed
below lib/<multiarch> and others (if there is not object library) are not.
With this patch all possible install locations of pkgconfig files are added
to the path if they exist.

The compiler might exit with nonzero exit code if given non-existent
options. Therefore we need to use set +e during this to make dunecontrol
to continue running even the options are not supported.

Some ^[$BLANK] or [^[$BLANK]^'], where $BLANK is space followed by tab
did not work as a capturing statement in some cases (e.g. opts files
with CONFIGURE_FLAGS="CXX='bla'"). After this patch we use [$NOBLANK]
with NOBLANK=^$space^$tab which works. In addition the other patches
form feature/posix-sed-dunecontrol have been backported to close flyspray
1401.

Unfortunately gcc-4.4 does not support --print-multiarch.
Therefore we fallback to cc -v and grep for the target in this case.

Debian uses multiarch-triplets (e.g. i386-gnu-linux) when installing
object libraries. These are installed to lib/$multiarch-triplet and not
to lib directly. In CMake this concept is partially supported by
GNUInstallDirs.cmake by setting CMAKE_INSTALL_LIBDIR to
lib/$multiarch-triplet. Unfortunately, this is only half the way through
as we also install libraries that do not differ between architectures (e.g.
our shell libraries.

This patch addes multiarch support for CMake to the best of my knowledge,
which might be limited, though:

- All not architecture dependent libraries are installed below the variable
  DUNE_INSTALL_NONOBJECTLIBDIR, which defaults to lib, but might be adjusted
  by the user.
- If the module ships an object library then the pkg-config and CMake package
  configuration files are installed in lib/$multiarch-triplet/pkg-config and
  lib/$multiarch-triplet/cmake/modules, respectively.
- If not then they are installed in lib/pkg-config and
  lib/cmake/modules, respectively.

Note that for autotool no such difference exists and always the latter approach
is used.

Previously, the macros were installed to $(datadir)/aclocal. As we have
some macros in DUNE that are also installed for some Linux distributions
this caused conflicts in package managers. With this patch we install
them to $(datadir)/dune/aclocal to resolve this issue outlined in flyspray
task 1409
https://dune-project.org/flyspray/index.php?do=details&task_id=1409

Previously only the include path of the local modules were used. This
caused errors with installed dune-common modules, similar to:

--> aclocal...

Error: Could not find dune-common/am!
Usage: dune-autogen DUNE_MODULE_PATH_LIST [options]
  --ac=, --acversion=VERSION   use a specific VERSION of autoconf
  --am=, --amversion=VERSION   use a specific VERSION of automake
  -h,    --help                you already found this :-)
--- Failed to build dune-typetree ---
Terminating dunecontrol due to previous errors!

This is also related to https://dune-project.org/flyspray/index.php?do=details&task_id=891

With this patch we include the aclocal, m4 or am directory of all modules
(installed and local ones) and everything works again as exspected.

With this patch the USE_CMAKE environment variable is queried whether or not CMake
should be used. This can be overwritten in an options file or on the command line
using either the --cmake or --no-cmakr switch.

Update minimal required versions to these mentioned in the documentation.
Quote argument in AC_PREREQ.
(Thanks to Bård Skaflestad for the heads-up)

Treating directories with spaces in autotools is a can of worms.
We now check whether this situation is given and issue an error when
building with autotools.

With this patch dunecontrol will work even if the path to the module
contains spaces. Unfortunately, the tests for dune modules will still
not work as I could not figure out how to use quoting in the CPP_FLAGS.

Previously the CMAKE variable was not set if no options file was used. This
fixes this.

With this patch it is possible to request CMake for building
by setting USE_CMAKE=yes in an option file.

In one of the latest patches I introduced a bug which caused
the --builddir option of dunecontrol to not make any effect.
This patch fixes this.