1. 17 Oct, 2019 1 commit
  2. 15 Oct, 2019 1 commit
  3. 01 Oct, 2019 1 commit
    • Brad King's avatar
      VS: Fix support for v142 toolset minor versions · 51173899
      Brad King authored
      When using `-T v142,version=14.22` the `.props` file location is
      different starting with version `14.20` than it was in `14.16` and
      below.  Adapt the path based on the version.
      Fixes: #19779
  4. 30 Aug, 2019 1 commit
  5. 31 Jul, 2019 1 commit
  6. 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
  7. 21 May, 2019 2 commits
  8. 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.
  9. 16 May, 2019 2 commits
  10. 14 May, 2019 1 commit
  11. 01 May, 2019 1 commit
  12. 12 Apr, 2019 1 commit
  13. 21 Mar, 2019 1 commit
  14. 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
  15. 19 Feb, 2019 1 commit
  16. 07 Feb, 2019 1 commit
  17. 04 Feb, 2019 3 commits
  18. 16 Jan, 2019 1 commit
    • Fred Baksik's avatar
      GHS: Add Compiler ID detection · 72e0c115
      Fred Baksik authored
      -- Detect GHS compiler and version
         Detect ARCHITECTURE_ID for PPC / ARM / 86 targets
         Detect PLATFORM_ID for Integrity and Integrity178 platforms
         Using defines specified in the documents for the compilers: 201416 PPC / 201754 ARM / 201714 86
      -- Fallback C/CXX compiler ID to GHS if not otherwise detected and using GHS MULTI generator
         Works around issue with some GHS compilers not setting __ghs__ compiler define
      -- Tweak Compiler ID checking so major id of 002017 is not replaced with 217
      -- Prefer try_compile() library targets when testing for working GHS compilers
      -- Avoid CMake errors if reading past end of file for checking if file is PE executable
  19. 15 Jan, 2019 1 commit
  20. 10 Dec, 2018 1 commit
    • Maikel van den Hurk's avatar
      Add Mach-O CMAKE_EXECUTABLE_FORMAT detection · c86e82c0
      Maikel van den Hurk authored
      Code for this was prototyped when ELF detection was added long ago but
      left commented out.  Use either MH_MAGIC or MH_CIGAM for the 32-bit
      variant and use either or MH_MAGIC_64 or MH_CIGAM_64 for the 64-bit
  21. 11 Sep, 2018 1 commit
  22. 24 Aug, 2018 1 commit
  23. 18 Jun, 2018 1 commit
  24. 29 May, 2018 1 commit
  25. 23 Apr, 2018 1 commit
  26. 28 Nov, 2017 1 commit
    • Ismail Donmez's avatar
      Clang: Do not mistake clang-cl 6.0 for GNU-like clang · f969f1a9
      Ismail Donmez authored
      The check added by commit v3.10.0-rc2~2^2 (Clang: Diagnose unsupported
      GNU-like clang targeting MSVC ABI, 2017-10-10) is incorrectly detecting
      clang-cl 6.0 as GNU-like.  Currently cmake is testing if the clang
      compiler accepts `--version` to see if it accepts GNU style flags.
      However, with the latest llvm snapshot this also works for clang-cl:
          > clang-cl --version
          clang version 6.0.0 (trunk)
          Target: x86_64-pc-windows-msvc
          Thread model: posix
          InstalledDir: C:\Program Files\LLVM\bin
      So instead we should use the `/?` flag which fails with clang but
      works with clang-cl:
          > clang-cl /? &> /dev/null; echo $?
          > clang /? &> /dev/null; echo $?
      Fixes: #17518
  27. 10 Oct, 2017 1 commit
    • Brad King's avatar
      Clang: Diagnose unsupported GNU-like clang targeting MSVC ABI · b6d3a1c0
      Brad King authored
      The LLVM/Clang installer on Windows provides a `LLVM/bin` directory
      containing `clang.exe` and `clang++.exe` command-line tools that have a
      GNU-like command-line but target the MSVC ABI (instead of MinGW).  We
      do not support this combination, so diagnose and reject it explicitly.
      Tell users what to do to use the `clang-cl.exe` tool instead.
      Issue: #16439
  28. 03 Oct, 2017 1 commit
  29. 19 Sep, 2017 2 commits
  30. 12 Sep, 2017 1 commit
  31. 23 Aug, 2017 1 commit
    • Brad King's avatar
      Ninja: Fix support for MSVC with non-English output · de9840d1
      Brad King authored
      With MSVC the Ninja generator extracts the `cl -showIncludes` prefix.
      When MSVC is configured to have non-English output, e.g. via
      `VSLANG=2052` in the environment, then `cl` prints the prefix encoded
      for the current code page, which is not necessarily UTF-8 encoding.
      Currently we fail to convert the prefix to our internal UTF-8 encoding,
      but assume it is UTF-8 later.
      While writing `rules.ninja`, the Ninja generator converts our internal
      UTF-8 encoding to the current code page.  The `msvc_deps_prefix =` line
      needs to be encoded as the current code page so that `ninja` can match
      in the output from `cl -showIncludes` during the build.
      Prior to commit v3.9.0-rc1~47^2 (codecvt: Re-implement do_out and
      do_unshift, 2017-05-25), the non-UTF-8 prefix extracted above was
      written without noticing its incorrect internal encoding.  The
      `rules.ninja` file was successfully written, but possibly with a mangled
      `msvc_deps_prefix`.  Since that commit the output stream correctly
      rejects the non-UTF-8 byte sequence and writing `rules.ninja` fails.
      Fix this by correctly converting the `cl -showIncludes` output from the
      current code page to our internal UTF-8 encoding.
      Fixes: #17191
  32. 29 Jun, 2017 2 commits
    • nolange's avatar
      IAR: Improve support for IAR ARM Compiler · d8e6cd9e
      nolange authored
      Make the implementation for this compiler more complete.
      IAR has multiple C++ modes, historically they were reduced c++ versions
      for embedded that gradually improved to the full standard (which can be
      reduced again by e.g. disabling rtti and exceptions).  The new
      implementation picks the best available, but the c++ mode can also be
      overridden by defining `CMAKE_IAR_CXX_FLAG`.
      Add C/C++ standard flags so that all modes up to and including the last
      supported standard are defined.
      Fixes: #16826
    • nolange's avatar
      Add a CMAKE_<LANG>_COMPILER_ARCHITECTURE_ID variable · 0b1a2876
      nolange authored
      Compilers such as MSVC and IAR may have variants that target different
      architectures.  We have been using a `MSVC_<LANG>_ARCHITECTURE_ID`
      variable to hold this information for MSVC.  Add an alternative with a
      more general name (later we can port MSVC to it too).
      This additional information may be needed to generate proper invocations
      of the compiler based on its architecture variant.
  33. 22 Apr, 2017 1 commit
  34. 31 Mar, 2017 1 commit
    • Brad King's avatar
      Xcode: Detect CURRENT_ARCH for use by generator · a1221905
      Brad King authored
      During compiler identification, extract the Xcode `CURRENT_ARCH` value
      and save it for later use by the Xcode generator in an internal compiler
      information variable.  This will be useful to know the locations of
      object files when only one architecture is built.