This removed the recently added prioritytag.hh
header again. Having a separate header for each
of these trivial helpers will only clutter the
directory and make people lookup the correct
header more often.

This header should be used to collect all utilities for
type computations, constraining overloads, and similar
purposes, that are not type-traits.

This can be used to 'store' an argument pack and access
its members. In contrast to a std::tuple<T...> which is
a container of objects of types T... a TypeList<T...>
only captures the types T... . Hence one can easily
create TypeList objects and use them to pass types around
or. e.g., in overload resolution where they can be used for
tag-dispatch.

This class is e.g. used in the concept checking facility
I'll add soon.

Notice that adding a template packer<T...> doing exactly
the same has been proposed for the standard in N4115

  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4115.html

If an iterator facade (like entity iterators) wants to allow the
embedded implementation to return either an (internally stored)
reference or a temporary object and expose these two behaviors to enable
performance optimizations, operator->() needs special handling: If the
implementation returns a reference, operator->() in the facade can
simply return the address of the referenced object, but if the returned
object is a temporary, we need to capture and store it in a helper
object to make sure it outlives the member access.

This patch adds a little helper function that tansparently handles both
cases.

These check whether std::call_once() works and provide a helpful error message
if it does not.  They should be used in any code that uses std::call_once().

Call once may not work if one forgets to _link_ with -pthread (or similar
options).  The nasty think about this is that linking still succeeds, so this
can only be detected at run time.  We cannot (in general) run compiled
programs during configure, since we may be cross-compiling, so whatever we get
from configure is at best a guess.

Even if configure detects the necessary flags correctly, there may still be
errors in the build system such that the executable is linked without them.

The reason to provide such a facility is that the bug is quite difficult to
debug when it appears.  The error message is mangled due to a different bug,
and is quite unhelpful anyway.  And then there is the fun with weak symbols...

IteratorRange is a cheap, throwaway container to implement support for
range-based for loops if the underlying containers doesn't provide
standard begin() / end () methods.

These headers were moved in Dune 2.3.

This implementation of an IdentityMatrix does not hold any data. It
implements a reduced version of the DenseMatrix interface including a
standard C++ cast operator to a Dune::FieldMatrix. This code illustrates
the new forward capabilities of DenseMatrixAssigner.

Thanks to Tobias Malkmus for the heads-up.

The majority of developers favor individual headers for (emulation of) C++11
features over collecting them in a single header cxx11.hh. This patch
renames cxx11.hh to constexpr.hh and moves it into the subdirectory std.
This is the place most developers would like these headers in (see
http://users.dune-project.org/doodles/4).

As decided on the developer meeting in Aachen, we support (but do not
rely on) the C++11 keyword constexpr. This patch adds an m4-check for
constexpr and a header (cxx11.hh) defining a macro DUNE_CONSTEXPR either
as constexpr or empty (depending on the compiler support for it). It is
then used in FieldVector and FieldMatrix on size, rows, and cols.

[[Imported from SVN: r7415]]

[[Imported from SVN: r7414]]

Initial message of blocked patch was : Adjusted CMakeLists.txt according to added files.

[[Imported from SVN: r7357]]

[[Imported from SVN: r7000]]

[[Imported from SVN: r6988]]

[[Imported from SVN: r6960]]

[[Imported from SVN: r6946]]

[[Imported from SVN: r6892]]

[[Imported from SVN: r6808]]

"lib1 lib2 lib3", which caused an error!)

[[Imported from SVN: r6755]]

[[Imported from SVN: r6748]]

[[Imported from SVN: r6747]]

libraries under the same name.

[[Imported from SVN: r6731]]

modul name (lower case with dashes).

These leads to kind of weired variabable names (dune-common_DIR,
dune-common_LIBRARIES, etc.) but finds non-installes modules
easier. You just sets CMAKE_PREFIX_PATH to the directory containing
the modules.

[[Imported from SVN: r6724]]

test directory is excluded from all and apparently not considered
during make install

[[Imported from SVN: r6674]]

infrastructure to use the module with cmake.

Currently, only an installed dune-common can be used, as the others
lack the cmake confguration files. One has to provide the
CMAKE_MODULE_PATH pointing to the directory where
e.g. DuneMacros.cmake is installed (PREFIX/share/cmake/modules) and 
DuneCommon_DIR pointing to PREFIXlib/cmake.

The ${CMAKE_BINARY_DIR}/config.h.cmake of the project is created such
that it includes section from modules that it depends on as well as
the ${CMAKE_SOURCE_DIR}/config.h.cmake. This prevents user from
creating a full file by hand.

Renamed package configuration files according to the style of the 
other modules.

[[Imported from SVN: r6661]]

have to specified during linking because it is implied by dunecommon.

[[Imported from SVN: r6644]]

Produce and install a preliminary  package configuration file.

[[Imported from SVN: r6641]]

  directories. This seems to be more manageable.
- Deactivated building of the test during make all. Seems annoying to
  our users.
- Introduced make check mimicing autotools.

Tests still fail where they should not.

[[Imported from SVN: r6610]]

The documentation is still not built and therefore not installed

[[Imported from SVN: r6602]]

Create libdunecommon.la in the right directory.

[[Imported from SVN: r6589]]