1. 29 Feb, 2016 2 commits
    • Steffen Müthing's avatar
      Merge branch 'feature/fix-cmake-documentation-without-doxylocal' into 'master' · 4b1fb7c8
      Steffen Müthing authored
      [cmake][bugfix] Make CMake Doxygen creation work for modules without Doxylocal
      
      When creating Doxygen documentation, CMake currently assumes that all
      modules have a Doxylocal file, which is in fact only present in
      dune-common right now. That file is then used as both a dependency and a
      file reading input, causing CMake errors.
      
      This patch fixes the problem by testing for the presence of Doxylocal
      and only including it in the build process if it was found.
      
      See merge request !61
      4b1fb7c8
    • Steffen Müthing's avatar
      [cmake][bugfix] Make CMake Doxygen creation work for modules without Doxylocal · bb02f3f3
      Steffen Müthing authored
      When creating Doxygen documentation, CMake currently assumes that all
      modules have a Doxylocal file, which is in fact only present in
      dune-common right now. That file is then used as both a dependency and a
      file reading input, causing CMake errors.
      
      This patch fixes the problem by testing for the presence of Doxylocal
      and only including it in the build process if it was found.
      bb02f3f3
  2. 28 Feb, 2016 1 commit
    • Steffen Müthing's avatar
      Merge branch 'fixes-static-scotch-metis-bindings' into 'master' · 834efd97
      Steffen Müthing authored
      [release] Fixes finding static scotch metis bindings
      
      Using Scotch a replacement work on Debian only for the default shared
      libraries. But to use the ones supporting larger integer types one needs
      to use the static version (shared ones are missing!). This MR fixes
      finding static Scotch/PT-Scotch instead of METIS/ParMETIS.
      
      Please cherry-pick to the release.
      
      See merge request !60
      834efd97
  3. 27 Feb, 2016 6 commits
  4. 25 Feb, 2016 2 commits
    • Carsten Gräser's avatar
      Merge branch 'feature/fix-bitsetvectortest-libc++' into 'master' · b28d5acf
      Carsten Gräser authored
      Fix compilation of bitsetvectortest with libc++
      
      The new version tests that a BitSetVectorConstReference can be converted
      to a bitset, which makes sense.
      
      The old version tested if a std::vector<bool>::const_reference could be
      converted to a bitset, which should not be assumed or tested, even
      though it works with libstdc++, apparently
      
      See also #18.
      
      See merge request !59
      b28d5acf
    • Elias Pipping's avatar
      Fix compilation of bitsetvectortest with libc++ · 355b813e
      Elias Pipping authored
      The new version tests that a BitSetVectorConstReference can be converted
      to a bitset, which makes sense.
      
      The old version tested if a std::vector<bool>::const_reference could be
      converted to a bitset, which should not be assumed or tested, even
      though it works with libstdc++, apparently
      
      See also #18.
      355b813e
  5. 24 Feb, 2016 5 commits
  6. 23 Feb, 2016 2 commits
  7. 22 Feb, 2016 3 commits
    • Christian Engwer's avatar
      Merge branch 'feature/add_check_all_bits_set_to_bitsetvector' into 'master' · faff0831
      Christian Engwer authored
      [feature] Add method 'all' to BitSetVectorConstReference
      
      I don't know if this is considered to be some proper interface change,
      but I would like to add the method 'all' to the BitSetVectorConstReference
      class which, in analogy to the present method 'none', returns 'true' if all
      bits of a block are set.
      
      See merge request !54
      faff0831
    • Jonathan Youett's avatar
      aca4b1af
    • Oliver Sander's avatar
      Merge branch 'feature/introduce-static-indices' into 'master' · 88cfef67
      Oliver Sander authored
      Introduce static indices _0, _1, _2 as shortcuts for std::integral_constant<std::size_t,0> etc.
      
      These indices have existed in dune-typetree for a while.  They are already used extensively
      in dune-typetree and dune-functions, and they also make working with MultiTypeBlockVector/Matrix
      from dune-istl much nicer.  They work very much like std::placeholders:_1, std::placeholders::_2,
      etc.  We would have like to use that, but there is no std::placeholders_0.
          
      This patch also introduces
          
          template<std::size_t i>
          using index_constant = std::integral_constant<std::size_t, i>;
          
      which helps decrease code verbosity a little bit.
      
      
      See merge request !44
      88cfef67
  8. 20 Feb, 2016 2 commits
    • Oliver Sander's avatar
      Export the new types 'reference' and 'const_reference' · 0b5c57f8
      Oliver Sander authored
      Just like std containers do.  This addition to the istl vector interface is
      necessary to do proper unit testing, because even though reference is value_type&
      for FieldVector, it is not for some other istl vectors.
      0b5c57f8
    • Steffen Müthing's avatar
      [DebugAllocator] Fix to work OS X < 10.11 · 6c343630
      Steffen Müthing authored
      OS X versions older than El Capitan (10.11) do not define MAP_ANONYMOUS,
      but only MAP_ANON. On the other hand, MAP_ANON is deprecated on Linux.
      
      So add a preprocesser switch to make both happy.
      6c343630
  9. 19 Feb, 2016 1 commit
  10. 18 Feb, 2016 4 commits
  11. 17 Feb, 2016 3 commits
    • Steffen Müthing's avatar
      Merge branch 'feature/cmake-rewrite-c++-standard-detection' into 'master' · 31252385
      Steffen Müthing authored
      [CMake] Rewrite C++ standard detection
      
      This is a complete rewrite of the existing C++ standard version test
      that tries the various `-std=c++xy` flags and tries to figure out which
      version of the standard to enable.
      
      The existing version has a few problems:
      
      - it is not really extensible to newer standards, those will just lead
      to a deeper and deeper nesting of `if` statements.
      
      - More importantly, there is no way to say: I want C++11, but not C++14
        (or, in the future, I want C++14, but not C++17). Being able to do so
        is important for testing and compatibility reason.
      
      - There is no easy way for downstream modules to require a newer version
        of the standard than the core modules.
      
      ## Test logic
      
      The new version of the test separates the logic from the data (versions,
      flag names, compiler test sources) and just iterates over lists of that
      data, in descending order to make sure the newest available standard
      gets picked. The numerical value of that standard is stored in the
      variable `CXX_MAX_SUPPORTED_STANDARD` and the test stops. If the test
      fails to find a working combination, it issues a warning to the user and
      only records support for C++03.
      
      The test can be influenced by two CMake variables:
      
      - `DISABLE_CXX_VERSION_CHECK` already existed in the old version of the
        test. It completely disables all testing and requires the user to
        manually set `CXX_MAX_SUPPORTED_STANDARD` to the correct value.
        Moreover, any required compiler command line switches have to be
        manually added to `CMAKE_CXX_FLAGS`.
      
      - `CXX_MAX_STANDARD` defines the maximum version of the standard that
        the build system will try to enable. With this new switch, it becomes
        possible to limit the compiler to an older version of the standard
        than what it could theoretically support. For now, this defaults to
        C++14.
      
      ## Requirements check with a new CMake function
      
      In order to allow module authors to easily state their minimum version
      requirements, there is a new CMake function
      `dune_require_cxx_standard()` that any Dune module can call to require
      support for at least a given C++ standard:
      
      ```
      dune_require_cxx_standard(MODULE "dune-functions" VERSION 14)
      ```
      
      If the compiler doesn't meet the requirements, the function will report
      the required and the actually available standard versions and abort with
      a fatal error.
      
      Moreover, it knows about CXX_MAX_STANDARD and will tell the user if the
      value of that variable is below the requirements. This avoids desperate
      users that have a shiny beta of GCC 6 with C++17 support wondering why
      their own module using shiny C++17 concepts stubbornly fails to build...
      
      This fixes #16, and a backport to 2.4 will also be a fix for #15.
      
      See merge request !46
      31252385
    • Christoph Grüninger's avatar
    • Christoph Grüninger's avatar
      [CMake] Remove spurious character in C++14 test · 9e7bdaba
      Christoph Grüninger authored
      Probably introduced accidentally in commit daa2e9f4.
      9e7bdaba
  12. 16 Feb, 2016 4 commits
  13. 15 Feb, 2016 5 commits
    • Steffen Müthing's avatar
      [CMake] It's -std=c++0x, of course · 0b825996
      Steffen Müthing authored
      Oops.
      0b825996
    • Steffen Müthing's avatar
      [CMake] Remove unused variable · 840eb992
      Steffen Müthing authored
      840eb992
    • Steffen Müthing's avatar
      [CMake] Add function to allow modules to require a minimum C++ standard · c5e82ed2
      Steffen Müthing authored
      This patch adds a new function dune_require_cxx_standard() that any Dune
      module can call to require support for at least a given C++
      standard. If the compiler doesn't meet the requirements, the function
      will report the required and the actually available standard versions
      and abort with a fatal error.
      
      Moreover, it knows about CXX_MAX_STANDARD and will tell the user if the
      value of that variable is below the requirements. This avoids desperate
      users that have a shiny beta of GCC 6 with C++17 support wondering why
      their own module using shiny C++17 concepts stubbornly fails to
      build... ;-)
      c5e82ed2
    • Steffen Müthing's avatar
      [CMake] Rewrite C++ standard detection test · daa2e9f4
      Steffen Müthing authored
      This patch is a complete rewrite of the existing C++ standard version
      test that tries the various -std=c++xy flags and tries to figure out
      which version of the standard to enable.
      
      While my cleaned-up version of the old implementation generally works,
      it has a few problems:
      
      - it is not really extensible to newer standards (that will lead to the
        same kind of mess as before).
      
      - More importantly, there is no way to say: I want C++11, but not
        C++14 (or, in the future, I want C++14, but not C++17). Being able to
        do so is important for testing and compatibility reason.
      
      So this patch mostly starts from scratch: There is a list of supported
      C++ standards (currently 17,14,11) and corresponding lists of compiler
      tests and compiler flags to switch the compiler to the respective
      standards (there might be different values for the switch, e.g. some
      compilers accept -std=c++1y, but not -std=c++14, and recent versions of
      GCC reject -std=c++1x).
      
      The code then just iterates through these versions and flags until it
      finds one that works. If that flag / version combo also passes the
      compile test, the maximum supported standard version is recorded in the
      variable CXX_MAX_SUPPORTED_STANDARD and the test stops. If the test
      fails to find a working combination, it issues a warning to the user and
      only records support for C++03.
      
      The test can be influenced by two CMake variables:
      
      - DISABLE_CXX_VERSION_CHECK already existed in the old version of the
        test. It completely disables all testing and requires the user to
        manually set CXX_MAX_SUPPORTED_STANDARD to the correct
        value. Moreover, any required compiler command line switches have to
        be manually added to CMAKE_CXX_FLAGS.
      
      - CXX_MAX_STANDARD defines the maximum version of the standard that the
        build system will try to enable. With this new switch, it becomes
        possible to limit the compiler to an older version of the standard
        than what it could theoretically support. For now, this defaults to
        C++14.
      daa2e9f4
    • Steffen Müthing's avatar
      [CMake] Clean up the C++ version flag detection and add final test that is always run · 79bd9732
      Steffen Müthing authored
      This patch cleans up the logic of the C++ version flag detection code,
      which had accumulated quite a bit of cruft over time.
      
      Moreover, it also adds a new test for basic C++11 compliance which is
      always run, even if DISABLE_CXX_VERSION_CHECK has been set. I think the
      original code was supposed to also error out in this case, but I didn't
      really do so.
      
      With this patch, DISABLE_CXX_VERSION_CHECK really only disables testing
      for the various -std=c++xy flags, but the build system will now always
      make sure that your compiler runs (at least) in C++11 mode.
      79bd9732