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.

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.

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.

According to the standard, all specializations of std::hash must export
argument_type and result_type [20.8.12/1]. The version of libc++ (LLVM's
alternative C++ standard library) tripped over this requirement on my
machine, so this patch adds the typedefs.

Ansgar fixed a bunch of problems in bigunsignedint - and improved the
corresponding test! yeah!

* p/ansgar/FS1644-bigunsignedint:
  Rework bigunsignedinttest.cc.
  bigunsignedint: Remove unneeded variable in operator%.
  bigunsignedint: Fix operator-.
  bigunsignedint: Throw an exception when constructing from a negative integer.
  bigunsignedint: make overload unambiguous for all integer types
  Use fixed-width integer types (C++11)

With just the two overloaded constructors

  bigunsignedint(int)
  bigunsigendint(uintmax_t)

trying to call the constructor with any integer type T different from
int and uintmax_t results in an ambiguous call: the promotion of T to
either int or uintmax_t are ranked the same. (Note that this does not
depend on the specific choice of int and uintmax_t.)

This patch provides a templated constructor for all signed integer
types which is ranked over the constructor taking an uintmax_t, making
overload resolution unambiguous for signed integer types. By also
"hiding" it for unsigned types using enable_if, the overload
resolution for unsigned integer types is also unambiguous; there is
only a single viable candidate left: the one taking an uintmax_t.

Use the fixed-width integer types introduced in C++11 instead of
making assumptions on the size of integers. The following changes were
implemented:

unsigned short used to store the bigunsignedint:
  Changed type to uint16_t. The implementation requires this to be a
  16-bit type.

int, unsigned int used to store intermediates:
  Changed type to (u)int_fast32_t. This is enough to hold sums, products
  or differences of two uint16_t integers.

std::size_t used as parameter in constructor and arithmetic operators:
  Changed type to uintmax_t. Any unsigned integer type should be usable
  in conjunction with bigunsignedint.

Return value of touint() member function:
  Changed type to uint_least32_t. The current implementation only
  returns the last two "digits" (of 16 bits each).

The test for __cxa_demangle(), which is used by Dune::className() to
demangle type names, doesn't work on my clang 3.6. Apparently, clang
requires the user to include <typeinfo> before <cxxabi.h>. While
classname.hh already does this, the build system tests don't, causing the
feature to get disabled on clang.

Fixed by adding the include to the build system tests.

A typo made it impossible to say 'no'.

Furthermore, I changed the text shown to the user to point to the
module documentation.

This change should make formatString safe to use in multi-threaded
programs.

This fixes FS#1636.