@Markus: too much CMake?! ;-)

There is not need to send message that contain no data. It might even
produce problems on  some implementation. Therfore this patch always
checks the size and simply sets the request to inactive (aka
MPI_REQUEST_NULL) if no data would be send or received.

The patch is to be cherry-picked to master if Christian approves.

We fix the option handling when calling "cmake --build", by prepending '--' to the command
line parameters, in order to separate cmake and build parameters, iff the user didn't alrready do
it himself so. Note that this means we assume that the users generally want to pass
parameters to the build command and not to cmake itself.

I accidentally commited them.

we again rethrow the exception, as some information is not available
in the parser routines.

This reverts commit 9281f717.

in order to improve error messages further we introduce a new member
variable prefix_. Sometimes it is important to pass subtrees around.
In this case it is difficult to interpret error messages, as the user
doesn't know in which subtree the problem occured. Now a Parametertree
knows its prefix and can tell it to the user. This way the report
method is simplified and the throws are now more readable.

This is e.g. needed for dune-alugrid and might be a first step for
getting rid off the ParMETIS dependency.

This reverts commit eb045a4d.

As it severly breaks using the make build system. See
https://dune-project.org/flyspray/index.php?do=details&task_id=1572

Since CMake 3.1 the if() command no longer automatically dereferences
variables named in quoted or bracket arguments.
This fixes FS#1567.

CMAKE_INSTALL_DATADIR already includes the subdirectory share, so drop
it from the install path of the dunecontrol bash-completion script in
the corresponding CMakeLists.txt.

mention cmake and CMAKE_FLAGS. Add an example for CMAKE_FLAGS in the
example opts file. Also update the compiler version in the example opts
file to a version that is actually supported by dune.

this makes new automake versions work like old automake versions. Some
of my projects used to compile objects in subdirs from parent directories.
New automake versions don't allow this. We don't want to atopt our
projects to changes in automake and make the transition to cmake... so
keep the old behaviour, by adding this option.

It caused that pthread.h was not found as clang does not like
to get -std=c++11 passed.

If an iterator facade (like entity iterators) wants to allow the
embedded implementation to return either an (internally stored)
reference or a temporary object and expose these two behaviors to enable
performance optimizations, operator->() needs special handling: If the
implementation returns a reference, operator->() in the facade can
simply return the address of the referenced object, but if the returned
object is a temporary, we need to capture and store it in a helper
object to make sure it outlives the member access.

This patch adds a little helper function that tansparently handles both
cases.

The ForLoop TMP used to put a number of restrictions on the arguments to
apply(), mainly due to the limited capabilities of C++01 wrt. to
argument forwarding.

But now we have C++11, so we can throw away all that awkward code and
replace it with a single forwarding function that supports arbitrary
numbers of arbitrary combinations of lvalues and rvalues - all hail
variadic templates and perfect forwarding!

This branch adds CMake macros for copying / symlinking files from the source
directory to the build directory and for adding a symlink back to the corresponding
directory in the source tree into every directory in the build tree.

* feature/FS1535-cmake-sourcedir-to-builddir-utilities:
  [CMake] Do copies as a fall-back if symlinks are not available on the platform
  [Cmake] Add macros for copying files from the source tree to the build tree.
  [CMake] add macro dune_symlink_to_source_files
  [CMake] Add macro dune_symlink_to_source_tree

Previously this was only set if run_default_configure was executed
before. Ergo dunecontrol make did try to use cmake even if USE_CMAKE=no
was set. This fixes flyspray 1560.
https://dune-project.org/flyspray/index.php?do=details&task_id=1560

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.

With a compiler name given to CMAKE_CXX_COMPILER (instead of a path),
the name is correctly expanded on the first run of cmake, but as soon
as the buil didrectory is existent, it is for obscure reasons expanded
into ${CMAKE_BINARY_DIR}/.... To avoid having users run into this bug,
the expanded compiler variable is matched with the build directory prefix.
In that case, an error is issued.

There is still a warning issued in that case.

Taken from #FS1535, where Carsten has posted this code.

It needs to be linked in some cases. The way of checking whether
it is needed is taken from Find{BLAS,LAPACK}.cmake . This fix was
needed as part of a larger fix for the test of parallel alugrid.

The UMFPack test has been added after CMake, so I simply
didnt know that it should be placed here, too.

The compatibility layer disabled MPI whenever it did not find
the --enable-parallel flag. This is overeager and harmful if users
are gradually switching to replacing the configure flags with real
cmake flags.

Consider an opts file, with the following content:
CMAKE_FLAGS="-DUSE_MPI=ON"

The compatibility layer would now parse the non-existent CONFIGURE_FLAGS
variable for an --enable-parallel option and disable MPI because it was
not found. The -DCMAKE_DISABLE_FIND_PACKAGE_MPI=TRUE supersedes the USE_MPI=ON
and we get a sequential build.

The fix applied in this patch removes the else clause and only adds
cmake flags when the --enable-parallel flag was found. To still explicitly
allow to force sequential builds, the --disable-parallel flag is parsed
in the same manner.

RECOMMENDED created new categories in the summary.
Technically there are no differences.

add symlinks to the build tree, which point to files in the source tree.
Foreach file given in "files", a symlink of that name is created in the
corresponding build directory. Use for ini files, grid files etc. A warning
is issued on Windows systems.