Merge branch 'feature/range-with-enums' into 'master'

Fixes the defect of the single argument range(...) that enum values could not
be used without casting. I would like to see this being backported to 2.6.

See merge request [core/dune-common!553]

  [core/dune-common!553]: gitlab.dune-project.org/core/dune-common/merge_requests/553

Merge branch 'simd-io' into 'master'

Apparently, output of Vc vectors does not work with libc++. I suspect it has
to do with some hackery Vc does in relation to the standard output streams.

This introduces syntax like

      std::cout << Dune::Simd::io(simd_vec) << std::endl;
      std::cout << Dune::Simd::vio(simd_vec) << std::endl;

to produce output like

    <1, 2, 3, 4>

The difference between the two versions is that io() will skip the angle
bracket for one-component vectors, while vio() will always print them.

See merge request [core/dune-common!551]

  [core/dune-common!551]: gitlab.dune-project.org/core/dune-common/merge_requests/551

Apparently, output of Vc vectors does not work with libc++.  I suspect it has
to do with some hackery Vc does in relation to the standard output streams.

This introduces syntax like
```c++
  std::cout << Dune::Simd::io(simd_vec) << std::endl;
  std::cout << Dune::Simd::vio(simd_vec) << std::endl;
```
to produce output like
```
<1, 2, 3, 4>
```

The difference between the two versions is that `io()` will skip the angle
bracket for one-component vectors, while `vio()` will always print them.

Merge branch 'debugalign-overload-min-max' into 'master'

A superficial reading of the standard's LessThanComparable requirement may
suggest that we could actually use std::min() and std::max(). But as it turns
out this isn't all that clear, see
<https://cplusplus.github.io/LWG/issue2114>. libc++ chose LessThanComparable
in a way that requires the result of the comparison to be implicitly
convertible to bool, which we cannot guarantee as we do not want the debug
type the automatically decay into its underlying type in all kinds of
contexts. So we go with the alternative route of overloading min() and max().

Adresses: [core/dune-istl#50]

See merge request [core/dune-common!550]

  [core/dune-istl#50]: gitlab.dune-project.org/core/dune-istl/issues/50
  [core/dune-common!550]: gitlab.dune-project.org/core/dune-common/merge_requests/550

A superficial reading of the standard's LessThanComparable requirement may
suggest that we could actually use std::min() and std::max().  But as it turns
out this isn't all that clear, see https://cplusplus.github.io/LWG/issue2114.
libc++ chose LessThanComparable in a way that requires the result of the
comparison to be implicitly convertible to bool, which we cannot guarantee
as we do not want the debug type the automatically decay into its underlying
type in all kinds of contexts.  So we go with the alternative route of
overloading min() and max().

Adresses: core/dune-istl#50

Merge branch 'bugfix/add_to_unique_ptr_to_CmakeLists' into 'master'

Header was missing in CMakeLists.txt and now breaks code due to usage in
dune-grid Needs to be backported to 2.6

See merge request [core/dune-common!547]

  [core/dune-common!547]: gitlab.dune-project.org/core/dune-common/merge_requests/547

Merge branch 'fix-clang-warning' into 'master'

Clang 6.0.1 does not know -Wbool-operation, and ignoring -Wpragmas is not
sufficient to shut it up about this. So ignore -Wunknown-warning-option too.

See merge request [core/dune-common!548]

  [core/dune-common!548]: gitlab.dune-project.org/core/dune-common/merge_requests/548

Clang 6.0.1 does not know -Wbool-operation, and ignoring -Wpragmas is not
sufficient to shut it up about this.  So ignore -Wunknown-warning-option too.

clang fails hard when encountering this option. Unfortunately, this
isn't checked for anywhere in the core modules, but causes build failures
for the PDELab CI images... :-(

See merge request core/dune-common!546

clang fails hard when encountering this option. Unfortunately, this isn't checked for anywhere in
the core modules... :-(

The current logic for placing / locating the virtualenv is rather flaky in combination with
installed modules or when `DUNE_PYTHON_VIRTUALENV_SETUP` was not enabled for all modules (as happens
in the CI images).

This MR improves the situation in two ways:

- It allows users to explicitly set `DUNE_PYTHON_VIRTUALENV_PATH` when running CMake. The build
  system will then use the given path for the virtualenv instead of guessing a location.

- When using an absolute build directory with dunecontrol, the virtualenv will no longer be placed
  inside the build directory of any module, but in the dedicated top-level directory
  `dune-python-env` inside the build directory root. This behavior can be disabled by setting
  `DUNE_PYTHON_EXTERNAL_VIRTUALENV_FOR_ABSOLUTE_BUILDDIR=0`.

See merge request core/dune-common!544

The current logic for placing / locating the virtualenv is rather flaky in combination with
installed modules or when `DUNE_PYTHON_VIRTUALENV_SETUP` was not enabled for all modules (as happens
in the CI images).

This patch improves the situation in two ways:

- It allows users to explicitly set `DUNE_PYTHON_VIRTUALENV_PATH` when running CMake. The build
  system will then use the given path for the virtualenv instead of guessing a location.

- When using an absolute build directory with dunecontrol, the virtualenv will no longer be placed
  inside the build directory of any module, but in the dedicated top-level directory
  `dune-python-env` inside the build directory root. This behavior can be disabled by setting
  `DUNE_PYTHON_EXTERNAL_VIRTUALENV_FOR_ABSOLUTE_BUILDDIR=0`.

Knowing whether `dunecontrol` was invoked with an absolute build directory can be very useful in CMake, as we can then place state that is shared between multiple modules directly in the build directory, e.g. the Python virtualenv.

See merge request core/dune-common!542

pip 10 moved several interfaces to an internal package, causing our pyversion.py script to fail.
This patches fixes the issue by getting installed distributions directly from setuptools, as
suggested in https://github.com/pypa/pip/issues/5243.

See merge request core/dune-common!540

pip 10 moved several interfaces to an internal package, causing our pyversion.py script to fail.
This patches fixes the issue by getting installed distributions directly from setuptools, as
suggested in https://github.com/pypa/pip/issues/5243.

See merge request core/dune-common!538

When the virtualenv support was added to the build system,
https://bugs.launchpad.net/debian/+source/python3.4/+bug/1290847# made us bail out
completely on building a virtualenv with preinstalled pip. The situation has improved
a lot since then; even Ubuntu 14.04 gets this right now as long as you install the
right packages. So let's be nice to our users and try whether installing pip works
before forcing them to do it manually or use `get-pip`. If a user insists on `get-pip`
by setting `DUNE_PYTHON_ALLOW_GET_PIP`, we skip this additional step and keep using
`get-pip`.

This shouldn't break anything, so I'll backport it to 2.6 as well, as it should make
it much easier to use the virtualenv in CI images (e.g. for
`dune-pdelab-systemtesting`, which requires `dune-testtools`).

See merge request core/dune-common!536

Way back when we first integrated a virtualenv into the Dune build process, there was a nasty bug in
several Linux distributions that made it impossible to get a standard virtualenv with pip installed
inside of it, so we decided to completely skip the default installation of pip into the virtualenv
and instead download get-pip to install it. This is not always appropriate, so now the flag
DUNE_PYTHON_ALLOW_GET_PIP has to be enabled for it, but without it enabled, we still force users to
manually install pip into the virtualenv.

Meanwhile, pretty much all distributions managed to get their act together (even Ubuntu 14.04 now
correctly installs pip into the virtualenv if the required packages are installed). In order to make
life easier for our users, this patch changes the default behavior: It now tries to create a
virtualenv with pip installed first, but if that fails, it reverts to the old behavior.

dune-ctest: do not print messages from failing tests twice

Closes #126

See merge request core/dune-common!535

CTest already prints the messages once.

Closes: #126

GCC 6.3 errors out with an ICE or simply hangs when instantiating a certain variant of `operator^=` on
`BitSetVectorReference`. This patch works around the problem by forcing the actual XOR instruction
into a separate function for that compiler. The workaround is probably horribly slow, but it
shouldn't have any impact on unaffected compilers.

This probably needs backporting.

See merge request core/dune-common!528

GCC 6.3 errors out with an ICE or simply hangs when instantiating a certain variant of operator^= on
BitSetVectorReference. This patch works around the problem by forcing the actual XOR instruction
into a separate function for that compiler. The workaround is probably horribly slow, but it
shouldn't have any impact on unaffected compilers.

This probably needs backporting.

This updates the CI configuration to use the new Docker images and their different toolchain
configuration. Note that this causes a build failure on Debian 9 with GCC 6 due to an ICE or
a compiler timeout. I'll push a separate MR to fix this issue, as the fix will need to be
backported.

See merge request core/dune-common!527