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.

"Makefile.in", "*.o", etc. need only be listed in the toplevel .gitignore, the
rules are applied recursively.

Test programs etc. should be listed as "/program" in their directory's
.gitignore, so they are not accidentially ignored in a lower level directory.

The AmiraMesh format is so obscure that we should not clutter the code we
generate by references to it.  If people really want AmiraMesh support they
can still add the flags, just like they have to do for many other things.

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.

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