1. 21 Jun, 2019 1 commit
  2. 17 Jun, 2019 1 commit
  3. 06 Jun, 2019 1 commit
    • Brad King's avatar
      Help: Document XLClang compiler id · 923f58ec
      Brad King authored
      This compiler id was added by commit 90c6156a (XLClang: Add a new
      compiler ID for the clang-based XL compiler, 2019-02-05,
      cpp-modules-20190312.1~71^2~7).  Add documentation accidentally left out
      of that commit.
      Issue: #18835
  4. 03 Jun, 2019 1 commit
  5. 27 May, 2019 1 commit
  6. 26 May, 2019 1 commit
  7. 24 May, 2019 1 commit
  8. 22 May, 2019 1 commit
  9. 21 May, 2019 2 commits
  10. 16 May, 2019 1 commit
  11. 14 May, 2019 2 commits
  12. 07 May, 2019 1 commit
  13. 03 May, 2019 1 commit
  14. 19 Apr, 2019 2 commits
    • Bill Hoffman's avatar
      execute_process: Add option to echo command lines · 044dcf9f
      Bill Hoffman authored
      Add COMMAND_ECHO option to the execute_process command. This will allow
      execute_process to show the command it will run. Also add a cmake variable
      CMAKE_EXECUTE_PROCESS_COMMAND_ECHO. Both the option and the variable can
      be set to one of the following: STDERR|STDOUT|NONE. The command will be
      printed to stderr or stdout or not at all.
      Fixes: #18933
    • 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
  15. 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
  16. 08 Apr, 2019 2 commits
  17. 04 Apr, 2019 1 commit
  18. 01 Apr, 2019 1 commit
  19. 27 Mar, 2019 1 commit
  20. 21 Mar, 2019 2 commits
  21. 15 Mar, 2019 1 commit
    • Robert Maynard's avatar
      export: Disable PACKAGE mode user package registry by default · 9bede5c4
      Robert Maynard authored
      The user package registry populated by the `export()` command causes
      side effects outside the build and source directories.  Such effects
      should be opt-in rather than op-out.  Introduce a policy to change
      default behavior of `export(PACKAGE)` to do nothing.
  22. 11 Mar, 2019 1 commit
  23. 06 Mar, 2019 3 commits
  24. 05 Mar, 2019 2 commits
  25. 25 Feb, 2019 1 commit
    • Brad King's avatar
      XLClang: Add policy CMP0089 to present as XL for compatibility · 5c413863
      Brad King authored
      We now identify IBM's Clang-based XL compilers, which define
      `__ibmxl__`, as `XLClang` rather than `XL`.  In order to support
      existing project code that checks for `XL`, add a policy whose OLD
      behavior is to present the compiler id as `XL` and whose NEW behavior is
      to present the compiler id as `XLClang` as we really detect it.
  26. 21 Feb, 2019 1 commit
  27. 20 Feb, 2019 1 commit
    • Brad King's avatar
      Fortran: Do not suppress explicit use of implicit include directories · 3dc81a48
      Brad King authored
      Since commit 2e91627d (ParseImplicitIncludeInfo: add Fortran implicit
      include handling, 2019-01-25, v3.14.0-rc1~73^2) we actually populate
      `CMAKE_Fortran_IMPLICIT_INCLUDE_DIRECTORIES` for the first time.  This
      value may be useful to project code to pass to other tooling that wants
      to preprocess the way Fortran does, so we should compute the value.
      However, compilers like `gfortran` do not actually search their own
      implicit include directories for `.mod` files.  The directories must be
      passed via `-I` in order for `.mod` files in them to be found.
      Since Fortran has no standard library header files that we need to avoid
      overriding, it is safe to *not* filter out implicit include directories
      from those passed explicitly via `-I` options.  Skip this filtering so
      that include directories specified by project code to find `.mod` files
      will be searched by the compiler even if they happen to be implicitly
      searched by the preprocessor.
      Fixes: #18914
  28. 16 Feb, 2019 1 commit
  29. 08 Feb, 2019 1 commit
  30. 04 Feb, 2019 1 commit
  31. 31 Jan, 2019 1 commit
  32. 30 Jan, 2019 1 commit