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.

are on Ubuntu.

This closes FS#1651.

Passing multiple files to dune_symlink_to_source_files() was broken.
While at it, I switched the given macros to be functions and have
named arguments. Using positional arguments will result in a warning.

For discussion check FS1648.

Disabling a cmake module through CMAKE_DISABLE_FIND_PACKAGE_...
was only partially working:
- Any module suggesting the disabled module would not search for it
- dunecontrol did not have this knowledge and built the disabled module nevertheless

This commit fixes the latter.

Viz., the question on whether all packages should be enabled by default.

This fixes FS 1647.

ptrdiff_t is a signed integer type and so the expression
  (std::uintptr_t)(ptr) % page_size
could become a negative value. In this case the page_ptr would be the
address of the next page after the allocation.

This wrong behaviour could be observed on (32bit) PowerPC: here
ptr was 0xf78cfe00 and page_ptr was calculated as 0xf78d0000 instead
of the correct 0xf78c0000.

The std::numeric_limits specialization for bigunsignedint requires
access to the internal state of bigunsignedint. Previously, the correct
specialization of std::numeric_limits was a friend of bigunsignedint,
but that creates problems on recent versions of clang with the
alternative libc++ library, because that library declares the base
template of std::numeric_limits as a class and clang subsequently
complains if the friend declaration uses 'struct'. Unfortunately,
libstdc++ uses a struct, making it impossible to keep clang happy for
both standard libraries. So we introduce a helper class that provides
access to the internal state and which now becomes a friend of
bigunsignedint. The numeric_limits specialization inherits from the
helper to use it.