1. 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
      923f58ec
  2. 03 Jun, 2019 1 commit
  3. 27 May, 2019 1 commit
  4. 26 May, 2019 1 commit
  5. 24 May, 2019 1 commit
  6. 22 May, 2019 1 commit
  7. 21 May, 2019 2 commits
  8. 16 May, 2019 1 commit
  9. 14 May, 2019 2 commits
  10. 07 May, 2019 1 commit
  11. 03 May, 2019 1 commit
  12. 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
      044dcf9f
    • 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
      db02be85
  13. 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
      compatibility.
      
      Fixes: #19108
      fb3370b6
  14. 08 Apr, 2019 2 commits
  15. 04 Apr, 2019 1 commit
  16. 01 Apr, 2019 1 commit
  17. 27 Mar, 2019 1 commit
  18. 21 Mar, 2019 2 commits
  19. 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.
      9bede5c4
  20. 11 Mar, 2019 1 commit
  21. 06 Mar, 2019 3 commits
  22. 05 Mar, 2019 2 commits
  23. 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.
      5c413863
  24. 21 Feb, 2019 1 commit
  25. 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
      3dc81a48
  26. 16 Feb, 2019 1 commit
  27. 08 Feb, 2019 1 commit
  28. 04 Feb, 2019 1 commit
  29. 31 Jan, 2019 1 commit
  30. 30 Jan, 2019 2 commits
  31. 29 Jan, 2019 1 commit