Otherwise it collides with the config.h.cmake for in-source builds.
The generated file is called config_collected.h.cmake.
Thanks to Robert for the heads-up.

Setting a policy must be guarded as older CMake version do not
know about the policy.

CMake >= 2.8.12 can optionally use @rpath to embed dynamic linker paths
into shared libraries on OS X. This greatly improves reliability with
libraries in non-standard locations and should definitely be turned on
by default.

script. This feature is disabled by default and can be enabled by
-DALLOW_CXXFLAGS_OVERWRITE=ON.

This branch fixes a number of problems related to
dune_enable_all_packages():

- The feature requires at least CMake 2.8.12, which is more recent than
  the baseline requirement of the core modules (2.8.12). We now check
  for that when executing the relevant functions and also remind the
  user to set the correct version in cmake_minimum_required().
- Updated the documentation to also state the version requirement.
- The duneproject script now also warns the user about the more
  stringent CMake version requirements when using the feature and sets
  the correct minimum required CMake version in the new module's main
  CMakeLists.txt file.
- There was a bug in duneproject that caused it to always enable
  dune_enable_all_packages(), ignoring the choice made by the user. That
  bug is fixed in this branch.
- Some minor fixes to duneproject while I was at it.

This fixes FS1678.

* feature/FS1678:
  [dunecontrol] Output choice of external package handling and required CMake version
  [duneproject] Allow specifying ENABLE_ALL as 5th command line argument
  [duneproject] Update CMake minimum version if ENABLE_ALL is true
  [duneproject][Bugfix] Make sure dune_enable_all_packages() can actually be disabled
  [CMake] Improve documentation in DuneEnableAllPackages.cmake
  [CMake][Doc] Add required CMake version to dune_enable_all_packages()
  [CMake] Require CMake 2.8.12 for dune_enable_all_packages()
  [CMake] Fix typo in warning message.
  Add a warning that some functions are 2.8.12

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.

dune_enable_all_packages() now requires CMake 2.8.12, so make sure
duneproject generates a correct template.

Also output a warning to tell the user about this change in required
CMake version.

The shell script logic for switching dune_enable_all_packages() on or
off in duneproject was broken and always turned the feature on, ignoring
the user input.

Fixed by testing for the actual contents of the variable instead of its
length and by converting the contents to lowercase before.

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

All the functionality in DuneEnableAllPackages.cmake is now contained in
functions instead of macros. Update the documentation to reflect that.

State the minimum required version of CMake in the documentation for
dune_enable_all_packages() and dune_target_enable_all_packages().

dune_enable_all_packages has to update the compiler options, but the
command compile_options only exists in CMake 2.8.12+. So we add a hard
requirement for that CMake version to the function.

I only ever intended this feature to work for CMake >= 2.8.12, so this
doesn't really change anything, except for giving the users a more
useful diagnostic.

Minimum required CMake version is 2.8.12 and not 2.9.12.

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.