1. 28 Apr, 2019 1 commit
  2. 23 Apr, 2019 1 commit
  3. 19 Apr, 2019 3 commits
    • Brad King's avatar
      MSVC: Do not add /W3 to CMAKE_<LANG>_FLAGS by default · 1baf122c
      Brad King authored
      We do not add default warning flags on other compilers, and having
      a warning flag in the default flags makes it hard for projects to
      customize the warning level.  They need to use string processing
      to remove `/W3` from `CMAKE_{C,CXX}_FLAGS`.  Therefore we should
      drop it.
      However, projects may be using string processing to replace `/W3`
      with another flag, so we cannot simply drop it.  Add a policy to
      drop it in a compatible way.
      Fixes: #18317
    • Brad King's avatar
      SunPro: Record support for C++14 features by SunPro 5.{14,15} · 66f3f11a
      Brad King authored
      SunPro 5.15 supports `-std=c++14` and several C++14 features.
      SunPro 5.14 accepts `-std=c++14` but does not update its definition of
      `__cplusplus` or any other macro to distinguish it from `-std=c++11`,
      so we need to blacklist a couple features that do work but that we
      cannot report for that version.  We can still support `cxx_std_14`.
      Co-Author: Robert Maynard <robert.maynard@kitware.com>
    • Brad King's avatar
      VS: Provide the default platform name to project code · db02be85
      Brad King authored
      The value of `CMAKE_VS_PLATFORM_NAME` is computed by Visual Studio
      generators based on `CMAKE_GENERATOR_PLATFORM` or some default.
      Prior to the VS 2019 generator, the default was always `Win32`.
      However, for the `Visual Studio 16 2019` generator, the default is
      based on the host platform.
      Store the default in a new `CMAKE_VS_PLATFORM_NAME_DEFAULT` variable for
      use by project code.  This is particularly useful in toolchain files
      because they are allowed to set `CMAKE_GENERATOR_PLATFORM` and so
      `CMAKE_VS_PLATFORM_NAME` is not yet known.  Of course the toolchain file
      author knows whether it will set `CMAKE_GENERATOR_PLATFORM`, and if not
      then `CMAKE_VS_PLATFORM_NAME_DEFAULT` provides the platform name that
      will be used.
      Fixes: #19177
  4. 18 Apr, 2019 2 commits
  5. 17 Apr, 2019 1 commit
    • Brad King's avatar
      MSVC: Add abstraction for runtime library selection · fb3370b6
      Brad King authored
      Replace our hard-coded defaults for `/MD` and `/MDd` with a first-class
      abstraction to select the runtime library from an enumeration of logical
      names.  We've long hesitated to do this because the idea of "runtime
      library selection" touches on related concepts on several platforms.
      Avoid that scope creep by simply defining an abstraction that applies
      only when targeting the MSVC ABI on Windows.
      Removing the old default flags requires a policy because existing
      projects may rely on string processing to edit them and choose a runtime
      library under the old behavior.  Add policy CMP0091 to provide
      Fixes: #19108
  6. 16 Apr, 2019 1 commit
  7. 15 Apr, 2019 4 commits
  8. 11 Apr, 2019 5 commits
  9. 10 Apr, 2019 6 commits
  10. 09 Apr, 2019 3 commits
  11. 08 Apr, 2019 5 commits
  12. 05 Apr, 2019 1 commit
  13. 04 Apr, 2019 2 commits
  14. 03 Apr, 2019 1 commit
  15. 01 Apr, 2019 2 commits
  16. 29 Mar, 2019 2 commits
    • Damien's avatar
      find_dependency: Always search dependencies · 37da6af1
      Damien authored
      When a dependency was already found, find_dependency did not search it
      again. While this works in basic case, it does not when there are
      components as the check does not take components into account.
      Given the fact that there is no documentation about this optimization and
      that the correct implementation is not trivial as it would require
      changes in find_package to have the list of components already found we
      always search dependencies.
      Fix #17583.
    • Brad King's avatar
      ParseImplicitIncludeInfo: Canonicalize implicit include dirs · dad86f18
      Brad King authored
      The implicit include directory extraction added by commit 5990ecb7
      (Compute implicit include directories from compiler output, 2018-12-07,
      v3.14.0-rc1~108^2) leaves paths like `/usr/lib/../include` unchanged.
      Fix the logic to canonicalize such paths (e.g. to `/usr/include`)
      as we do for implicit link directories already.  This is important
      to ensure the set of implicit directories is represented in the same
      form as the include directories that will be compared to them.
      Issue: #19095