summaryrefslogtreecommitdiffstats
path: root/Modules/CMakeDetermineCompilerId.cmake
Commit message (Collapse)AuthorAgeFilesLines
* Merge topic 'cuda_host_compiler_fail'Brad King2020-09-011-3/+6
|\ | | | | | | | | | | | | | | 01428c5560 CUDA: Fail fast if CMAKE_CUDA_ARCHITECTURES doesn't work during detection 9f81aa0f69 CUDA: Fail if compiler detection using the host compiler fails Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5155
| * CUDA: Fail if compiler detection using the host compiler failsRaul Tambre2020-08-291-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Add ISPC compiler support to CMakeRobert Maynard2020-08-281-0/+22
|/
* Toolchain: Take CMAKE_<lang>_FLAGS_INIT into account during compiler detectionFred Baksik2020-07-291-1/+3
| | | | Fixes: #20040
* Fix typos identified using codespellJean-Christophe Fillion-Robin2020-07-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See https://github.com/codespell-project/codespell#readme The following command was used: ``` codespell -q6 --skip="\ .git,\ *.json,\ ./Copyright.txt,\ ./Help/command/foreach.rst,\ ./Help/prop_test/REQUIRED_FILES.rst,\ ./Help/variable/CTEST_COVERAGE_COMMAND.rst,\ ./Modules/CMakeCheckCompilerFlagCommonPatterns.cmake,\ ./Modules/CMakeRCInformation.cmake,\ ./Modules/Internal/CPack/NSIS.template.in,\ ./Modules/FindMatlab.cmake,\ ./Modules/MatlabTestsRedirect.cmake,\ ./Modules/Platform/Windows-Clang.cmake,\ ./Modules/Platform/Windows-Intel-Fortran.cmake,\ ./Modules/Platform/Windows-MSVC.cmake,\ ./Source/CMakeVersion.cmake,\ ./Source/cmConvertMSBuildXMLToJSON.py,\ ./Source/cmCreateTestSourceList.cxx,\ ./Source/cmGlobalVisualStudio10Generator.cxx,\ ./Source/cmExportBuildFileGenerator.cxx,\ ./Source/cmExportInstallAndroidMKGenerator.cxx,\ ./Source/cmExportInstallFileGenerator.cxx,\ ./Source/cmExportSet.cxx,\ ./Source/cmExportTryCompileFileGenerator.cxx,\ ./Source/cmFindPackageCommand.cxx,\ ./Source/cmInstallCommand.cxx,\ ./Source/cmGeneratorExpressionLexer.cxx,\ ./Source/cmLocalVisualStudio7Generator.cxx,\ ./Source/cmOrderDirectories.cxx,\ ./Source/cmTarget.cxx,\ ./Source/kwsys/*,\ ./Source/QtDialog/CMakeSetupDialog.ui,\ ./Source/CPack/WiX/cmWIXRichTextFormatWriter.cxx,\ ./Source/CTest/cmParseCoberturaCoverage.h,\ ./Tests/CMakeTests/ImplicitLinkInfoTest.cmake.in,\ ./Tests/RunCMake/CPack/tests/DMG_SLA/English.license.rtf,\ ./Tests/RunCMake/CPack/tests/DMG_SLA/German.license.txt,\ ./Tests/RunCMake/CPack/tests/DMG_SLA/German.menu.txt,\ ./Tests/RunCMake/GoogleTest/xml_output.cpp,\ ./Tests/RunCMake/Make/TargetMessages*,\ ./Utilities/*,\ " \ -L "\ dependees,\ endwhile,\ fo,\ filetest,\ helpfull,\ nd,\ objext,\ stoll,\ supercedes,\ superceded,\ vas,\ varn,\ " ```
* Merge topic 'xcode-native-arch'Craig Scott2020-07-211-0/+6
|\ | | | | | | | | | | | | | | 26673bf480 Xcode: Explicitly specify default native architecture on macOS ce624cfbd4 cmGlobalXCodeGenerator: Save CMAKE_SYSTEM_NAME in member Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5023
| * Xcode: Explicitly specify default native architecture on macOSBrad King2020-07-201-0/+6
| | | | | | | | | | | | | | | | | | | | | | 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
* | Visual Studio: Add Android supportKyle Edwards2020-06-241-4/+25
|/
* Merge branch 'backport-cuda-default-runtime' into cuda-default-runtimeBrad King2020-05-221-1/+5
|\
| * CUDA: Compute CMAKE_CUDA_RUNTIME_LIBRARY default from toolchainRobert Maynard2020-05-211-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 0d0145138f (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
| * Merge topic 'vs-clangcl' into release-3.17Brad King2020-03-271-1/+3
| |\ | | | | | | | | | | | | | | | | | | f3d7a15010 VS: Fix ClangCL toolset compiler path detection Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !4523
* | \ Merge topic 'vs-clangcl'Brad King2020-03-271-1/+3
|\ \ \ | | |/ | |/| | | | | | | | | | | | | f3d7a15010 VS: Fix ClangCL toolset compiler path detection Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !4523
| * | VS: Fix ClangCL toolset compiler path detectionBrad King2020-03-261-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to commit 3c125c6de0 (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
* | | Merge topic 'nmc-cl-showincludes'Brad King2020-03-271-1/+1
|\ \ \ | | |/ | |/| | | | | | | | | | | | | | | | 6c7e6b1e49 Ninja Multi-Config: Fix MSVC showincludes prefix detection Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: Kyle Edwards <kyle.edwards@kitware.com> Merge-request: !4526
| * | Ninja Multi-Config: Fix MSVC showincludes prefix detectionBrad King2020-03-261-1/+1
| |/ | | | | | | | | | | Activate the detection logic for this generator too. Fixes: #20506
* | ASM: Record vendor-specific output matched to identify assemblerBrad King2020-03-121-0/+1
| | | | | | | | | | | | For example, with GNU `as`, we match `GNU assembler`, but with GNU `gcc` as the assembler, we do not match anything. Distinguishing these cases may be useful for constructing assembler command lines.
* | CMakeDetermineCompilerId: Set locale to C for vendor output matchBrad King2020-03-121-0/+13
|/ | | | | | Apply the change from commit d751d2d2ed (CMakeDetermineCompilerABI: set locale to C for try_compile(), 2019-01-14, v3.14.0-rc1~108^2~1) to the `CMAKE_DETERMINE_COMPILER_ID_VENDOR` implementation too.
* CUDA: MSVC generators fill CMAKE_CUDA_TOOLKIT_INCLUDE_DIRECTORIESRobert Maynard2020-01-101-1/+2
| | | | | | Fixes #18733 Correct an oversight where the MSVC generators didn't populate CMAKE_CUDA_TOOLKIT_INCLUDE_DIRECTORIES.
* Merge topic 'backport-3.16-vs-v142-version'Brad King2019-12-131-3/+4
|\ | | | | | | | | | | | | | | | | 2f853eec3d Merge branch 'backport-3.15-vs-v142-version' into backport-3.16-vs-v142-version d8d4924d98 VS: Fix support for v142 toolset minor versions in VS 16.5+ 07612646fe VS: Fix support for v142 toolset minor versions in VS 16.5+ Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !4133
| * VS: Fix support for v142 toolset minor versions in VS 16.5+Brad King2019-12-121-3/+4
| | | | | | | | | | | | | | | | | | | | The fix in commit 5117389931 (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
* | VS: Support Visual Studio Clang Toolkit identificationJustin Goshi2019-12-051-1/+1
| | | | | | | | | | Teach CMake that the `ClangCl` toolset uses the `ClangClExecutable` value as the path to the compiler executable.
* | XL: Add support for Ninja and XL FortranBrad King2019-11-211-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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` underneath. Fixes: #19450
* | VS: Propagate CMAKE_VS_GLOBALS into compiler id projectsAlexander Boczar2019-10-171-0/+6
| | | | | | | | Issue: #19708
* | VS: Add support to override VCTargetsPath through toolsetAlexander Boczar2019-10-151-0/+3
|/ | | | Fixes: #19708
* Merge topic 'vs-v142-version'Brad King2019-10-021-1/+7
|\ | | | | | | | | | | | | 5117389931 VS: Fix support for v142 toolset minor versions Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !3874
| * VS: Fix support for v142 toolset minor versionsBrad King2019-10-011-1/+7
| | | | | | | | | | | | | | | | 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
* | cuda: Extend cuda compiler detection to work with custom cuda pathBenjamin Wozniak2019-08-301-2/+8
| |
* | Merge topic 'clang-cl-non-windows'Brad King2019-08-021-1/+1
|\ \ | |/ | | | | | | | | | | 863f7eb6d7 clang: Restore support for clang-cl on non-Windows hosts Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !3634
| * clang: Restore support for clang-cl on non-Windows hostsBrad King2019-07-311-1/+1
| | | | | | | | | | | | | | | | | | The frontend variant detection logic added by commit 53fbe23f3f (clang: introduce CMAKE_<lang>_COMPILER_FRONTEND_VARIANT, 2019-02-20, v3.15.0-rc1~41^2~8) assumes that `clang-cl` only runs on a Windows host. It is also available on non-Windows hosts. Fix the condition. Fixes: #19544
* | CMakeDetermineCompilerId: Consider UTF-16 encodings of INFO stringsBrad King2019-07-111-4/+8
|/ | | | | | | | | | | 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
* Merge topic 'clang-gnulike-support'Brad King2019-05-291-36/+28
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 74829f01b1 Help: Add notes for topic 'clang-gnulike-support' 19669abe1d Tests: handle string escaping differences with NMake+clang a2a90f41e3 Tests: require C++14 for the Tutorial 4819ff9647 Tests: fix failures with gnu mode clang on windows 26af0b25e7 cmake: use correct stack size with gnu mode clang on windows d44c0db0b2 clang: setup correct configuration in gnu mode b7d5ef23e9 cmGlobalNinjaGenerator: use gnu compatible paths with clang in gnu mode 3d0210d8dc binutils: add the llvm-* variants to the tool lists. ... Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: Francesco Bertolaccini <francesco@bertolaccini.dev> Acked-by: Stanislav Ershov <digital.stream.of.mind@gmail.com> Acked-by: Saleem Abdulrasool <compnerd@compnerd.org> Merge-request: !2992
| * clang: introduce CMAKE_<lang>_COMPILER_FRONTEND_VARIANTZsolt Parragi2019-05-171-36/+28
| | | | | | | | | | | | | | | | 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.
* | Merge topic 'vs-ApplicationTypeRevision'Brad King2019-05-221-2/+2
|\ \ | | | | | | | | | | | | | | | | | | | | | 9c07cefee5 VS: Fix ApplicationTypeRevision in builtin check projects 639e14def6 VS: Factor out helper to compute ApplicationTypeRevision Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !3350
| * | VS: Fix ApplicationTypeRevision in builtin check projectsBrad King2019-05-211-2/+2
| | | | | | | | | | | | | | | | | | | | | Do not use the entire `CMAKE_SYSTEM_VERSION`, but rather the first two components only. Fixes: #19275
* | | IAR: Do not print compiler architecture id for non-IAR compilersBrad King2019-05-211-1/+1
|/ / | | | | | | | | | | | | The compiler identification message was modified in commit ea83d0f8fb (IAR: Generalize and add support for IAR RX compiler, 2019-04-05) to include the architecture id since IAR compilers are arch-specific. Revise the logic to avoid modifying the message for other compilers.
* | Swift: Detect compiler versionBrad King2019-05-161-0/+24
| |
* | CMakeDetermineCompilerId: Make CMAKE_${lang}_COMPILER available earlierBrad King2019-05-161-7/+8
| | | | | | | | | | If compiler id detection gave us the compiler tool, copy its value to the `CMAKE_${lang}_COMPILER` variable as early as possible.
* | ARMClang: Add support for Clang-based ARM compilerJohan Stridkvist2019-05-141-0/+1
|/ | | | Fixes: #18215
* CMakeDetermineCompilerId: Support versioned LLVM for Visual Studio.Zufu Liu2019-05-021-1/+1
| | | | | | | | | | Supports versioned LLVM toolsets like LLVM_v142, LLVM_v141, LLVM_v141_xp, etc. for Visual Studio (2010 and later). The name for versioned LLVM toolsets has "LLVM_" prefix plus MSVC toolset name (i.e. v142, v141, v141_xp, etc.). Fixes: #19203
* IAR: Generalize and add support for IAR RX compilerStefan Andersson2019-04-121-1/+8
| | | | Moved common ASM setup to the common macros and changed version check.
* GHS: Add support for GHS Multi Generator in LinuxNaren Manimohan2019-03-211-3/+11
|
* Merge topic 'vs-llvm-extension'Brad King2019-02-271-2/+9
|\ | | | | | | | | | | | | 8375c303e2 VS: Fix detection of clang-cl with -T llvm Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !3024
| * VS: Fix detection of clang-cl with -T llvmBrad King2019-02-261-2/+9
| | | | | | | | | | | | | | | | | | | | | | 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
* | Use -? instead of /? to test compiler for MSVC-like command-line supportBrad King2019-02-191-1/+1
|/ | | | | | | | MS-style command-line tools accept either `/` or `-` for command-line options. Prefer `-` over `/` so that non-MS tools do not treat it as a path. Fixes: #18941
* Xcode: Derive stdlib from CXX flagsGregor Jasny2019-02-071-0/+9
| | | | Closes: #18396
* Merge topic '17870-iphone-friendly-cmake'Brad King2019-02-051-12/+5
|\ | | | | | | | | | | | | | | | | e8ee8cab97 Xcode: Completely disable code signing for compiler id detection 11da882a12 Apple: Introduce separate system name for iOS, tvOS, and watchOS 36cf44a7a3 Tests: Isolate RunCMake.XcodeProject per-device cases from host arch Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !2392
| * Xcode: Completely disable code signing for compiler id detectionGregor Jasny2019-02-041-12/+0
| | | | | | | | Issue: #17870
| * Apple: Introduce separate system name for iOS, tvOS, and watchOSGregor Jasny2019-02-041-1/+6
| | | | | | | | | | | | | | | | | | | | | | - Remove code signing requirements for non-macOS - Do not set deployment target for non-macOS - Build static library for compiler feature detection for non-macOS - Use framework to run CompilerId tests for watchOS - Port tests to new SDK handling - Add new Apple cross-compiling section to toolchain documentation Closes: #17870
* | Xcode: Update default Swift language version for Xcode 10.2Brad King2019-02-041-0/+2
|/ | | | | | Xcode 10.2 no longer supports Swift language versions before 4.0. Fixes: #18871
* GHS: Add Compiler ID detectionFred Baksik2019-01-161-21/+64
| | | | | | | | | | | | -- 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
generated by cgit v0.12 at 2025-01-06 23:55:19 (GMT)