1. 06 Dec, 2020 1 commit
    • Nikita Sirgienko's avatar
      CMakeDetermineCompilerId: support Intel DPC++ compiler toolset for VS gen · 7808cbd6
      Nikita Sirgienko authored and Nikita Sirgienko's avatar Nikita Sirgienko committed
      Before Intel have only one compiler icl (Intel(R) C++ compiler) and
      CMakeDetermineCompilerId has considered, that all toolchains with a word
      "Intel" in the toolchain name is a icl compiler. But now Intel have also other
      compiler - Intel(R) DPC++ compiler, which haven't working with cmake on
      Visual Studio Generator because cmake try to use icl compiler, which cmake
      can't found and because of this fails the configuration. This commit fix
      this problem, and both compilers start to work correctly with
      Visual Studio generator.
      Fixes: #21546
  2. 03 Dec, 2020 3 commits
  3. 29 Nov, 2020 1 commit
    • Marc Chevrier's avatar
      Makefiles Generators: use compiler for dependencies generation · 2c71d051
      Marc Chevrier authored
      Each source compilation generates a dependencies file. These dependencies
      files are consolidated in one file per target. This consolidation is done
      as part of command 'cmake -E cmake_depends` launched before evaluation of
      makefile dependency graph.
      The consolidation uses the same approach as `CMake` dependencies management.
      Fixes: #21321
  4. 25 Nov, 2020 1 commit
    • Raul Tambre's avatar
      CUDA: Fix user-set architectures during detection with Visual Studio · 20807a18
      Raul Tambre authored and Brad King's avatar Brad King committed
      If the user specifies CMAKE_CUDA_ARCHITECTURES we use those during detection
      and error out if they don't work.
      For Visual Studio a dummy project file is used instead of invoking the compiler
      directly. NVCC would thus use its default and we'd fail if
      CMAKE_CUDA_ARCHITECTURES was anything other than NVCC's default.
      Use the necessary project file variable in CMakeDetermineCompilerId.cmake to
      match other generators.
      Fixes #21492.
  5. 12 Nov, 2020 1 commit
  6. 29 Aug, 2020 1 commit
    • Raul Tambre's avatar
      CUDA: Fail if compiler detection using the host compiler fails · 9f81aa0f
      Raul Tambre authored
      If an user specified a host compiler we should fail if we are unable to perform
      compiler detection with it.
      Previously we would try without and likely succeed and continue. Then we'd fail
      during ABI detection and compiler testing since we'd still try to use it.
      This is particularly problematic when crosscompiling since we extract the host
      linker from the compiler detection link line. This would result in the wrong
      host linker being used and a linking error due to architecture mismatch during
      ABI detection where other necessary flags may already be present to make the
      host compiler work. See #21076 for an example.
      Fix this by adding CMAKE_<LANG>_COMPILER_ID_REQUIRE_SUCCESS to
      CMakeDetermineCompilerId, which throws a fatal error if executing the compiler
      results in a non-zero exit code.
      Fixes #21120.
  7. 28 Aug, 2020 1 commit
  8. 29 Jul, 2020 1 commit
  9. 22 Jul, 2020 1 commit
    • Jean-Christophe Fillion-Robin's avatar
      Fix typos identified using codespell · 20737380
      Jean-Christophe Fillion-Robin authored and Brad King's avatar Brad King committed
      See https://github.com/codespell-project/codespell#readme
      The following command was used:
      codespell -q6 --skip="\
      " \
      -L "\
  10. 20 Jul, 2020 1 commit
    • Brad King's avatar
      Xcode: Explicitly specify default native architecture on macOS · 26673bf4
      Brad King authored
      When `CMAKE_OSX_ARCHITECTURES` is not specified, we add the Xcode
      setting `ONLY_ACTIVE_ARCH = YES` with the intention of targeting the
      native architecture of the host.  However, the default `ARCHS` value
      chosen by "Xcode 12 Universal Apps" includes multiple architectures.
      Add an explicit `ARCHS` setting with value `$(NATIVE_ARCH_ACTUAL)`
      to tell Xcode to use the host's native architecture only.
      Fixes: #20893
  11. 24 Jun, 2020 1 commit
  12. 21 May, 2020 1 commit
    • Robert Maynard's avatar
      CUDA: Compute CMAKE_CUDA_RUNTIME_LIBRARY default from toolchain · e55b21e2
      Robert Maynard authored and Brad King's avatar Brad King committed
      Since commit 0d014513 (CUDA: Add abstraction for cuda runtime
      selection, 2019-11-29, v3.17.0-rc1~83^2) we add CUDA runtime library
      selection flags by default.
      To maintain backwards compatibility the default CUDA runtime
      library needs to be computed based on what libraries are found
      on the initial compiler invocation. For example a toolchain
      could establish initial flags that have all CUDA compilations
      using the runtime version, and if we don't detect this we will
      try to link to both the static and shared runtime.
      Co-Author: Brad King <brad.king@kitware.com>
      Fixes: #20708
  13. 26 Mar, 2020 2 commits
    • Brad King's avatar
      Ninja Multi-Config: Fix MSVC showincludes prefix detection · 6c7e6b1e
      Brad King authored
      Activate the detection logic for this generator too.
      Fixes: #20506
    • Brad King's avatar
      VS: Fix ClangCL toolset compiler path detection · f3d7a150
      Brad King authored
      Prior to commit 3c125c6d (VS: Support Visual Studio Clang Toolkit
      identification, 2019-12-03, v3.17.0-rc1~341^2) using `-T ClangCL`
      would work but `CMAKE_{C,CXX}_COMPILER` would be detected as `cl.exe`
      even though `clang-cl.exe` is the actual compiler.  That commit
      attempted to fix the detection by using `$(ClangClExecutable)`
      as we do for LLVM-distributed toolsets, but that is not actually
      defined.  Instead, look for `$(CLToolExe)` in the `PATH`.
      Fixes: #20504
  14. 12 Mar, 2020 2 commits
  15. 10 Jan, 2020 1 commit
  16. 12 Dec, 2019 2 commits
    • Brad King's avatar
      VS: Fix support for v142 toolset minor versions in VS 16.5+ · d8d4924d
      Brad King authored
      The fix in commit 51173899 (VS: Fix support for v142 toolset minor
      versions, 2019-10-01, v3.16.0-rc1~32^2) worked around a bug in VS's
      placement of toolset files.   VS 16.5 will fix that bug and restore the
      original pattern for locations of toolset files.  Update our logic to
      look for both possibilities.
      Issue: #19779
    • Brad King's avatar
      VS: Fix support for v142 toolset minor versions in VS 16.5+ · 07612646
      Brad King authored
      The fix in commit 51173899 (VS: Fix support for v142 toolset minor
      versions, 2019-10-01, v3.15.5~6^2) worked around a bug in VS's placement
      of toolset files.   VS 16.5 will fix that bug and restore the original
      pattern for locations of toolset files.  Update our logic to look for
      both possibilities.
      Issue: #19779
  17. 05 Dec, 2019 1 commit
  18. 21 Nov, 2019 1 commit
    • Brad King's avatar
      XL: Add support for Ninja and XL Fortran · 19f267c7
      Brad King authored
      The Ninja generator's support for Fortran requires that source files
      be preprocessed explicitly first.  However, the `xlf` compiler does
      not have a simple `-E` option or equivalent to do preprocessing.
      The only documented way to get preprocessed output is to use `-d`
      to leave it behind, but only at an inflexible location.
      Instead, create our own `cpp` wrapper script and substitute it for the
      real preprocessor using `-tF -B ...`.  Teach the wrapper to map the
      `cpp` output to the location we need and then invoke the real `cpp`
      Fixes: #19450
  19. 17 Oct, 2019 1 commit
  20. 15 Oct, 2019 1 commit
  21. 01 Oct, 2019 1 commit
  22. 30 Aug, 2019 1 commit
  23. 31 Jul, 2019 1 commit
  24. 11 Jul, 2019 1 commit
    • Brad King's avatar
      CMakeDetermineCompilerId: Consider UTF-16 encodings of INFO strings · d1f38ba6
      Brad King authored
      Our compiler identification source encodes `INFO:compiler[...]` and
      similar strings in compiled objects or binaries that we then extract to
      get information about the compiler.  With most compilers the strings are
      encoded in the binaries as a simple byte sequence.  However, some
      compilers use other encodings.  For example, the MS CSharp compiler uses
      UTF-16LE and a TI compiler uses UTF-16BE.  Try each encoding.
      Fixes: #19459
  25. 21 May, 2019 2 commits
  26. 17 May, 2019 1 commit
    • Zsolt Parragi's avatar
      clang: introduce CMAKE_<lang>_COMPILER_FRONTEND_VARIANT · 53fbe23f
      Zsolt Parragi authored
      This variable is set to GNU on Windows when clang.exe ar clang++.exe is
      used, and set to MSVC for clang-cl.exe.
      CMAKE_<lang>_SIMULATE_ID is set to MSVC in both cases, as clang defaults
      to -fms-compatibility for all command lines on windows.
  27. 16 May, 2019 2 commits
  28. 14 May, 2019 1 commit
  29. 01 May, 2019 1 commit
  30. 12 Apr, 2019 1 commit
  31. 21 Mar, 2019 1 commit
  32. 26 Feb, 2019 1 commit
    • Brad King's avatar
      VS: Fix detection of clang-cl with -T llvm · 8375c303
      Brad King authored
      When using a VS generator with `-T llvm`, MSBuild relies on the "LLVM
      Compiler Toolchain" VS Extension.  This does not put `clang-cl` in the
      `PATH` inside the build, and LLVM no longer provides a `cl` replacement
      either.  Therefore we need another way to extract the path to the
      `CMAKE_{C,CXX}_COMPILER`.  Fortunately the LLVM VS integration provides
      a `$(ClangClExecutable)` macro we can reference to get the path.
      Fixes: #18983
  33. 19 Feb, 2019 1 commit