It sets LOCAL_USE_CMAKE for the current module depending on USE_CMAKE
and whether there actually is CMake support for this module.
This will make it more easy to use the same check in all run_*
directives.

Previously we did not catch patterns at the start of the line.
Seems like sed cannot handle [ ^] as the meaning of
^ is the not operator here and not the line beginning.

Unfortunately environment variables with these names are not honored by CMake's
FindMPI. Therefore this commit translates them to MPI_{C,CXX}_COMPILER and
adds them to CMAKE_FLAGS before calling cmake.

When deciding which variable to put before cmake as environment variables
our sed pattern did not check for the beginning of a word or line. Therefore
MPICC=bla would be converted to CC=bla.
With this commit we make sure that there is eihter a beginning of a line or
a whitespace before the variable.

This enables ninja-build and other build systems to be called
correctly.
Targets can be passed by adding "--target <targetname>

The warning was spilled out for every module for every command,
even for update.
The build directory is announced by CMake's configure anyway.
Now it is printed for make, too.

CMAKE can now be set in the shell or the opts file, if both are set
the shell has higher priority.
This feature was dropped in …aef001c21e3a9 to fix FS#1518.

The only case we do not want to use the build-dir is
when explicitly autotools are used.

CMAKE is nom handled similar to MAKE.
CMAKE is no longer evaluated in the opts file as this would overwrite
a CMAKE set by the dunecontrol call.
This fixes FS#1518.

Once CMake will be default, people can deactivate it.

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.