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.

Andreas Nüßing authored 10 years ago and Christoph Grüninger committed 10 years ago

When creating a project and generating the config.h.cmake file, duneproject
surrounds the inserted text with {begin,end} $NAME. $NAME is set to $PROJECT
without a leading "dune[-_]" and $PROJECT is the module name specified by the
user (e.g. $PROJECT==dune-grid, $NAME==grid).
When DuneMacro.cmake generates the config.h.cmake for the created project in
the build-directory, it searches the config.h.cmake file in the source
directory of the project for {begin,end} $ProjectName which is set to
DUNE_MOD_NAME, which is the module name specified in the corresponding
dune.module file (e.g. dune-grid).
This leads to DuneMacro not finding and therefore ignoring the block in the
source config.h.cmake of the new project.

Complained by autoconf 1.14, cf. FS#1462.
Thanks to Claus for the heads-up.

Cf. FS#1461.

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 :-)

Module names with hyphens are no longer changed to
underscores.
This fixes FS#1432.

Previously running the installed mpi-config failed as mpi-config.m4
was not found. This patch corrects the path to it in the script and
fixes the problem.

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.)

Before this patch we tried setting am_dir for directory with a
DUNE module. If one is working with local modules
(e.g. dune-common and dune-geometry), that are a subset of installed
modules (e.g. dune-common, dune-geometry, and dune-istl), that are all
installed under the same prefix, then modules that are part of the difference
of the set of installed and the set of the local modules caused am_dir to
point to the am directory of the installed dune-common directory.
After this patch  am_dir is only set once, which fixes this behaviour and
flyspray issue #1420

Fixes flyspray issue 1418, see https://dune-project.org/flyspray/index.php?do=details&task_id=1418

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.

A variable was not correctly escaped during creation of the file
cmake/modules/Makefile.am causing the error message:
"duneproject: line 914: datadir: command not found."

This patch now correctly escapes it.

duneproject failed miserably when run with only installed modules. With
this patch we correctly setup the pkg-config and dunecontrol path to
handle this situation. In addition we fixed various issues with the newly
created modules and they now build as exspected.

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.