1. 12 Dec, 2017 1 commit
  2. 20 Nov, 2017 3 commits
  3. 15 Nov, 2017 3 commits
    • Brad King's avatar
      Merge branch 'FindOpenGL-glvnd-preference' into release-3.10 · 47c2baf0
      Brad King authored
      Merge-request: !1485
    • Brad King's avatar
      FindOpenGL: Add option to prefer GLVND for legacy GL · ff3c11ee
      Brad King authored
      Since commit v3.10.0-rc5~3^2 (FindOpenGL: Default to non-GLVND libraries
      for legacy GL, 2017-11-08) users may set `OPENGL_gl_LIBRARY` to empty to
      use GLVND components for the legacy GL interfaces.  This is useful only
      when one knows in advance that the GLVND components will be found.
      Add a `OpenGL_GL_PREFERENCE` variable to specify a preference for legacy
      GL or GLVND.  The latter can suppress `OPENGL_gl_LIBRARY` only when the
      needed GLVND components are found.  If no preference is explicitly
      specified, choose a default based on whether GLVND components were
      requested (because this indicates the project has been updated for
      CMake 3.10).
      Issue: #17437
      Issue: #17449
    • Brad King's avatar
      FindOpenGL: Re-order component library searches · aadc38c7
      Brad King authored
      Move the search for the legacy GL library to after the GLVND libraries.
      For now we still always look for both.
  4. 14 Nov, 2017 1 commit
  5. 13 Nov, 2017 2 commits
  6. 10 Nov, 2017 5 commits
  7. 09 Nov, 2017 2 commits
    • Brad King's avatar
      Merge branch 'FindOpenGL-no-glvnd-for-GL' into release-3.10 · 1f153248
      Brad King authored
      Merge-request: !1466
    • Brad King's avatar
      FindOpenGL: Default to non-GLVND libraries for legacy GL · e6b209c8
      Brad King authored
      Projects using `OPENGL_LIBRARIES` or `OpenGL::GL` expect legacy GL.
      Although GLVND OpenGL+GLX provides legacy GL interfaces, using those
      library files may conflict with legacy GL library files used by
      dependencies (or dependents) of such projects.  Therefore we should
      not yet use OpenGL+GLX when a legacy GL library is available.
      If `OPENGL_gl_LIBRARY` is set then use it as the legacy GL library.
      If it is *not* set then fall back to using GLVND OpenGL+GLX to provide
      legacy GL interfaces.  This will allow users to build projects using
      GLVND even if they have not been ported.
      Fixes: #17437
  8. 08 Nov, 2017 4 commits
    • Brad King's avatar
      Merge branch 'FindHDF5-c-version' into release-3.10 · 24ca3369
      Brad King authored
      Merge-request: !1465
    • Axel Huebl's avatar
      FindHDF5: Fix H5_VERSION on Patch in C · a6abb6c8
      Axel Huebl authored
      Fix a typo from commit v3.6.0-rc1~85^2 (HDF5: Refactor the use of
      compiler wrappers, 2016-04-04) that accidentally used the HDF5 C++
      version (which could be empty) while detecting the C patch version.
      The detection failed for patch releases, such as `1.10.0-patch1`
      becoming `.1` instead of ``.
    • Brad King's avatar
      Merge branch 'implicit-lib-gcceh' into release-3.10 · ddf48551
      Brad King authored
      Merge-request: !1460
    • Christian Pfeiffer's avatar
      Restore exclusion of "gcc_eh" from implicit link libraries · 41aacca7
      Christian Pfeiffer authored
      Since commit v3.9.0-rc1~148^2 (Do not assume GCC libs are linked by all
      compilers, 2017-05-05) we no longer filter out all `gcc*` implicit link
      libraries.  This allows mixing of gcc and non-gcc compilers across
      languages.  However, this caused a subtle problem with how GCC makes
      exception handling symbols available to linked binaries.
      GCC (at least on MinGW) provides two different libraries with exception
      handling symbols:
      * gcc_s: A shared library with -fvisibility=default, used by -shared-libgcc.
      * gcc_eh: A static library with -fvisibility=hidden, used by -static-libgcc.
      The C compiler (on MinGW) defaults to -static-libgcc and uses gcc_eh.
      The C++ compiler defaults to -shared-libgcc and uses gcc_s when linking
      shared libraries and executables so that exceptions can propagate across
      shared libraries [1].  When linking a mixed-language binary, the C++
      compiler should be used along with its choice of gcc_s.  In this case
      gcc_eh should not be added even though the C compiler implies it because
      gcc_s supersedes it.
      Since the above-mentioned change, CMake is adding gcc_eh to C++ link
      lines that also contain C code on MinGW.  This causes both gcc_s and
      gcc_eh to be used, which is incorrect.  We can fix this simply by
      excluding gcc_eh from the C compiler's implicit link libraries.
      [1] https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Link-Options.html#Link-Options
      Fixes: #17436
  9. 07 Nov, 2017 4 commits
  10. 06 Nov, 2017 2 commits
  11. 01 Nov, 2017 3 commits
    • Brad King's avatar
      CMake 3.10.0-rc4 · 45da5587
      Brad King authored
    • Brad King's avatar
      Merge branch 'mingw-clang-c-compile-features' into release-3.10 · 8d1341f4
      Brad King authored
      Merge-request: !1435
    • Brad King's avatar
      Record C compile features flags for MinGW Clang on Windows · f86879a0
      Brad King authored
      This was done for C++ by commit v3.5.0-rc1~69^2 (Record compile features
      for MinGW Clang on Windows, 2016-01-11).  Make the same change for C.
      The `UNIX` condition on Clang C compiler features was already dropped by
      refactoring in commit v3.9.0-rc1~17^2~4 (Compilers: Port to use default
      cmake_record_lang_compile_features macros, 2017-05-10).
      Our documentation already claims support for this combination.  This
      was simply an oversight when support was added for MinGW Clang C++.
      Issue: #15897
      Issue: #15943
  12. 31 Oct, 2017 3 commits
  13. 30 Oct, 2017 5 commits
  14. 28 Oct, 2017 1 commit
  15. 27 Oct, 2017 1 commit