With the recent changes to bigunsignedint, the index cannot
be initialized with a negative value anymore. We change this
to 1 to overcome the problem.

This commit together with the recent bugfixes by Ansgar
fixes the AMG code on master.

Since 0c697d8d messages of size zero
are no longer sent. This can reduce the number of requests we have to
wait for.

The storage of bigunsignedint was changed to std::uint16_t in commit
541b3dfc. This implements the same
change for the MPITraits<bigunsignedint<k>>

Note that this assumes that
  MPITraits<std::uint16_t>
is defined. This is the case as long as uint16_t maps to one of the
standard integer types (unsigned char/short/int/long).

Thanks to Markus for pointing this out.

Reference: https://dune-project.org/flyspray/index.php?do=details&task_id=1657#comment6393

The duncontrol / dune.module mechanism allowes to overload the run_* commands, which
are executed in order to setup/build/etc. a module. This patch fixes a bug in the cmake
parsing of the dune.module file. Somehow cmake tried to interpret the content of the
dune.module as cmake code. We now use a different strategy to parse the file and avoid
storing the content in a temporary variable.

>> please backport to 2.4

This bug could only be found outside Germany :D

This document gathers some beginners question about the CMake
build system. It is built during make doc and made available
on the website through the doc installation.

the first problem was that I accidentially enabled the ScalarOrderingTest, but this forced me
to investigate further and I found out how this works, or not works.

We have to add the comparison operators to FieldVector, as the cast operator does not always
match, e.g. in the case of GMPField.

Before the test was not active since '#if HAVE_GMP' fails
if the gmp-flags where not added.

This fixes bug FS#1665

* we introduce limit the constructor of GMPField to match only those
  types which can initialize the underlying mpf_class
* we extend the FieldVector<K,1> constructors to accept all scalar
  types which are compatible to K
* we update DenseVector to use ADL to find functions like max(...),
  otherwise it would fail for GMPField

in order to make GMPField work in more situations, we add a constrctor, which matches
all scalar data types, which can me converted to K.
We deliberately exclude K from the template match.

we first import function like std::max into the local scope and the call max(a,b) instead of
std::max(a,b). This allows to match specializations for other data types via ADL.

The templated constructor of GMPField fatched everything. We reduce the constructor
to those scalar values, which are convertible to mpf_class. As this removes the constructor
from char* we explicitly add constructor from char* and std::string.

This is the main part to fix FS#1665

most of the tests work. std::complex<GMPField> does not work as expected, but this is
perhaps something we don't want to support. As std::complex does not allow to initialize
with other parameters than the data type itself, we can not initialize from int or other
compatible scalar values. The smae problem occures when interacting with int values directly.

Those create a lot of output (basically what method uses what other method
and what method is used by what other method), which I doubt a whole lot
of people find useful.  Turning them off makes the html output much more
pleasant to read.

BOOST_FOUND seems to be no longer known, use
HAVE_DUNE_BOOST instead.

Affected are older CMake versions 2.8.6 to 2.8.9 maybe even,
newer versions.

Fixes FS#FS#1649.

dune_library_add_sources() verifies the library name against the
contents of DUNE_ENABLE_ALL_PACKAGES_MODULE_LIBRARIES. I accidentally
broke this by converting dune_enable_all_packages (which defines the
variable) from a macro to a function, which removed the variable from
global scope.

This patch fixes the problem by explicitly exporting the variable to the
parent scope, making it available to dune_library_add_sources() again.

We have to call add_definitions() in a loop because add_definitions() is
kind of broken: even though it is supposed to be *the* function for
adding compile definitions, it does not prepend "-D" (as opposed to
target_compile_definitions(), which does). Well, whatever...

Thanks for spotting that, Dominic!

This branch resolves somes smaller problems with the
dune_enable_all_packages() feature and importantly provides support for
modules with libraries and CMake < 3.1.

* feature/FS1654-improve-dune-enable-all-packages:
  [Release][CMake] Add support for compile options in DuneEnableAllPackages
  [Release][CMake][Bugfix] Use correct test in if() command
  [Release][CMake] Add dune_target_enable_all_packages()
  [Release][CMake][Bugfix] Remove stray unset() command
  [Release][CMake] Convert macros to functions in DuneEnableAllPackages
  [Release][CMake] Improve documentation in DuneEnableAllPackages.cmake

We do not really support this combination of C++11 features, and the
only time it should occur is when the user has a recent Intel Compiler
and an outdated GCC (which the Intel Compiler uses for the C++ standard
library). In that case, we emit a helpful error message at configuration
time.

This patch adds a new function dune_target_enable_all_packages() that
works like dune_enable_all_packages(), but only acts on the given list
of targets.

This function is mostly needed to be able to use the new
dune_enable_all_packages() feature in a DUNE module that defines its own
libraries. Specifically, the "nice" default way of handling those
libraries only works on CMake 3.1+. To be compatible with older CMake
versions, the library has to be manually added in the top-level
CMakeLists.txt file before the call to dune_enable_all_packages(). But
the library also needs to get all the package flags from the DUNE
modules the current one depends on, which can be done using the new
function added by this patch.

All of the macros in DuneEnableAllPackage cause their side effects by
modifying properties, so there is no point in having them as macros,
which are more fragile than functions and pollute the outside variable
scope.

- Fix some typos
- Improve wording
- Try to be clearer about the distinction between CMake modules and DUNE
  modules

on Ubuntu.