summaryrefslogtreecommitdiffstats
path: root/Modules/CMakeDetermineCompilerId.cmake
Commit message (Collapse)AuthorAgeFilesLines
* CUDA: Add support for CUDA_ARCHITECTURES=nativeBrad King2022-03-101-1/+1
| | | | | | | | | | | CUDA 11.6 added the `nvcc -arch=native` flag to automatically compile for the host GPUs' architectures. Add support for specifying this special `native` value in `CMAKE_CUDA_ARCHITECTURES` and `CUDA_ARCHITECTURES`. During the compiler ABI detection step, detect the native architectures so we can pass them explicitly when using Clang or older versions of nvcc. Fixes: #22375
* CUDA: Restore support for CMAKE_CUDA_ARCHITECTURES=OFFRobert Maynard2022-03-091-1/+1
| | | | Fixes: #23309
* VS: Fix CUDA compiler id with CMAKE_CUDA_ARCHITECTURES={all,all-major}Brad King2022-03-021-4/+6
| | | | | | | | Skip the architecture verification check for these values on Visual Studio. It cannot be implemented correctly until future work delays the check to the main compiler test step. Issue: #23164, #23161
* Merge topic 'vs-intel-oneapi-toolset'Brad King2021-12-171-5/+3
|\ | | | | | | | | | | | | 612c0d49f4 VS: Fix detecting icx.exe with Intel Compiler toolsets newer than 2021 Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !6806
| * VS: Fix detecting icx.exe with Intel Compiler toolsets newer than 2021William R. Dieter2021-12-151-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The logic added by commit 7808cbd644 (CMakeDetermineCompilerId: support Intel DPC++ compiler toolset for VS gen, 2020-12-06, v3.20.0-rc1~330^2) matches a specific toolset known to be the `icx.exe` compiler, and assumes all other Intel C++ compilers (that are not DPC++) must be `icl.exe`. Since `icx.exe` is officially replacing `icl.exe`, use a regex that matches the now-fixed set of toolsets known to use `icl.exe`. Any other Intel C++ compiler will be assumed to be `icx.exe`. Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
* | GHS: Update selection of primaryTarget in MULTI project fileFred Baksik2021-11-151-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Changes to ``-A`` handling: * Don't force CMAKE_GENERATOR_PLATFORM into cache when using default value (breaks using CMake presets). * Don't print message when using default value (breaks CMake tests). Changes to ``GHS_PRIMARY_TARGET`` handling: * Add as a cache variable so its known to GUI * Don't always include``GHS_TARGET_PLATFORM``, it's only needed if ``GHS_PRIMARY_TARGET`` wasn't set by the user. * Set ``GHS_PRIMARY_TARGET`` during platform selection instead of when a language is enabled. By performing this sooner ``GHS_TARGET_PLATFORM`` is not always required to be set into cache.
* | Merge topic 'vs-framework-version'Brad King2021-11-081-0/+9
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | d51246c662 VS: Default TargetFrameworkVersion to v4.7.2 for VS 2022 f97f8537f3 VS: Model a default target framework e40cedddc0 cmVisualStudio10TargetGenerator: Refactor target framework selection 78782cc7dc cmGlobalVisualStudio8Generator: Refactor SetGeneratorPlatform Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !6699
| * | VS: Model a default target frameworkBrad King2021-11-061-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add fields to the VS generator to select a target framework. Migrate the existing default for VS 12 .NET CF for Windows CE. Report the values in `CMAKE_VS_*` variables and use them for the CSharp compiler id project too. Issue: #22849
* | | LCC: Add policy CMP0129 regarding interpreting LCC as GNUmakise-homura2021-10-211-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Due to MCST LCC compiler identification is now changed to LCC, there should be a way for old projects to still identify it as GNU, as it was before. This commits adds the policy: CMP0129: Compiler id for MCST LCC compilers is now LCC, not GNU. This policy controls such a behavior. OLD behaivior is to treat LCC as GNU, NEW is to treat is as LCC.
* | | LCC: Add dedicated support for MCST LCC compilermakise-homura2021-10-151-1/+1
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Divert LCC compiler as a new one, instead of treating it as GNU. Since old times, Elbrus C/C++/Fortran Compiler (LCC) by MCST has been passing checks for GNU compilers, so it has been identified as GNU. Now, with intent of seriously upstreaming its support, it has been added as a separate LCC compiler, and its version displays not a supported GCC version, but LCC version itself (e.g. LCC 1.25.19 instead of GNU 7.3.0). This commit adds its support for detection, and also converts basically every check like 'is this compiler GNU?' to 'is this compiler GNU or LCC?'. The only places where this check is untouched, is where it regards other platforms where LCC is unavailable (primarily non-Linux), and where it REALLY differs from GNU compiler. Note: this transition may break software that are already ported to Elbrus, but hardly relies that LCC will be detected as GNU; still such software is not known.
* | Xcode: Fix detection of default language standard when given -std= flagsBrad King2021-10-061-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If one uses `CFLAGS='-std=...'` or `CXXFLAGS='-std=...'` then the given `-std=` flag(s) will always be used. That effectively changes the compiler default standard level and extension settings. Fix the Xcode generator's compiler id logic to preserve any `-std=` flag so that the proper defaults are detected. This problem was exposed by commit 4a0485be7f (cmStandardLevelResolver: Avoid unnecessary flags, fix unset level logic, 2021-05-29), which changed the logic to not pass any `-std=` flag if the standard level and extension settings requested by the project match the default (`stdIt <= defaultStdIt` became `stdIt < defaultStdIt`). The new logic assumes the detected default standard matches what will actually happen when the project is generated.
* | CMakeDetermineCompilerId: Tolerate variables named for languagesBrad King2021-10-061-1/+1
| |
* | CompilerID: Compiler extensions default detectionRaul Tambre2021-09-281-0/+5
| |
* | CompilerID: Rename language_dialect to language_standardRaul Tambre2021-09-281-1/+1
| | | | | | | | | | In Linux C++ terms dialect usually refers to having GNU extensions or not. Change the name to better reflect that this is about the standard version.
* | Merge topic 'hip-no-hipcc'Brad King2021-09-201-35/+0
|\ \ | |/ | | | | | | | | | | | | | | | | | | | | | | cb93f72624 HIP: Simplify detection of HIP runtime CMake package a71f0fc9c7 HIP: Remove ROMClang compiler id and use Clang directly b125e9809a HIP: Detect ROCm path earlier 735f41fc2d HIP: Use 'rocm_agent_enumerator' to determine CMAKE_HIP_ARCHITECTURES Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: buildbot <buildbot@kitware.com> Acked-by: Raul Tambre <raul@tambre.ee> Acked-by: Axel Huebl <axel.huebl@plasma.ninja> Merge-request: !6533
| * HIP: Remove ROMClang compiler id and use Clang directlyBrad King2021-09-161-24/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit bd844387df (ROCMClang: Add the ROCm toolkit derived clang compiler to CMake, 2020-08-28, v3.21.0-rc1~66^2~6) and commit ff0d2858e1 (HIP: Extract clang compiler details from hipcc, 2020-10-21, v3.21.0-rc1~66^2~5), the separate `ROCMClang` compiler id for `hipcc` has caused a few problems: * The compiler id changed from behavior of CMake 3.20 and below, breaking projects that already built with `hipcc` treated as `Clang`. * The implementation of `target_compile_features` was incomplete for the `ROCMClang` identity. * Only `hipcc` was identified as `ROCMClang`, so after it is unwrapped to the underlying `clang++`, future runs of new CMake versions on an existing build tree would not repeat this. * Clang should be usable as a HIP compiler without the `hipcc` wrapper. Remove the `ROMClang` compiler identity, and revise HIP language support to work directly with a Clang compiler. Reject direct `hipcc` usage as a HIP compiler. For now it cannot be supported because it interferes with flags CMake needs to pass to Clang. Fixes: #22536, #22460, #22593
| * HIP: Detect ROCm path earlierBrad King2021-09-161-11/+0
| | | | | | | | | | | | | | | | | | Fail early if it is not found. Use the detected location as a hint to find `rocm_agent_enumerator`. Also remove the leading `_` prefix in case we want to document this publicly later.
* | Merge topic 'enable_language-CMP0126'Brad King2021-07-201-4/+0
|\ \ | |/ | | | | | | | | | | f75610d492 CMakeDetermineCompilerId: Fix CMAKE_EXECUTABLE_FORMAT in CMP0126 NEW behavior Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !6364
| * CMakeDetermineCompilerId: Fix CMAKE_EXECUTABLE_FORMAT in CMP0126 NEW behaviorBrad King2021-07-191-4/+0
| | | | | | | | | | | | | | | | Setting `CMAKE_EXECUTABLE_FORMAT` as a normal variable is unnecessary because setting it as a cache entry already makes the value visible to the calling scope. Fixes: #22433
* | Intel/Fortran: Avoid recording warning 5117 lines in CMakeError.logMichael Hirsch2021-07-061-2/+5
|/
* HIP: Extract clang compiler details from hipccRobert Maynard2021-06-071-0/+35
|
* ROCMClang: Add the ROCm toolkit derived clang compiler to CMakeRobert Maynard2021-06-071-1/+0
|
* Modules: Fix typos and spelling in commentsJosef Angstenberger2021-05-071-1/+1
|
* FujitsuClang: Use GNU-like command-linePaul Zehner2021-04-141-0/+2
|
* Merge topic 'flags-with-backslash'Brad King2021-04-081-5/+6
|\ | | | | | | | | | | | | 3953dfcb31 Restore support for backslashes in initial language-wide flags Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5995
| * Restore support for backslashes in initial language-wide flagsBrad King2021-04-071-5/+6
| | | | | | | | | | | | | | | | | | | | Refactoring in commit bdc40742bd (CMakeDetermineCompilerId: Test without COMPILER_ID_FLAGS if REQUIRE_SUCCESS, 2021-02-27, v3.20.0-rc3~6^2) added an extra macro layer through which flag strings are passed. That caused an extra level of argument re-parsing, and broke flags with backslashes. Pass flags to the helper macro through variable names instead. Fixes: #22041
* | Fujitsu: Add support for the Fujitsu compiler in Trad modeChuck Atkins2021-03-301-2/+23
| | | | | | | | Co-Author: Yuichiro Utsumi <utsumi.yuichiro@jp.fujitsu.com>
* | VS: switch to new folder structure while keeping the old one workingMarcel Ritzschke2021-03-181-3/+13
|/ | | | Fixes: #21170
* CMakeDetermineCompilerId: Fix REQUIRE_SUCCESS with multiple user flagsRaul Tambre2021-03-021-1/+1
| | | | Need to quote the list expansion otherwise we'll try each argument separately.
* CMakeDetermineCompilerId: Test without COMPILER_ID_FLAGS if REQUIRE_SUCCESSRaul Tambre2021-02-271-16/+34
| | | | | | | If we REQUIRE_SUCCESS, i.e. TEST_FLAGS_FIRST must work, we need to also try without user flags. Fixes #21869.
* CMakeDetermineCompilerId: Recognize XCOFF executable formatBrad King2021-02-031-0/+5
|
* IntelLLVM: Add support for Intel LLVM-based compilersWilliam R. Dieter2021-01-281-1/+2
| | | | | | | | | | | | | | | | | | Using a single ID 'IntelLLVM' for the suite of Intel compilers based on the LLVM backend. The 'IntelLLVM' ID are used for C, C++, and Fortran. Data Parallel C++ will be handled in a separate commit. The C and C++ definitions are based on the Clang definitions. The Intel LLVM-based C and C++ compilers are based on the Clang front end, so existing Clang options are more likely to be a good match than options for the older Intel compilers. Fortran is based on the older Fortran front end with the LLVM backend. It has a similar interface to the older versions, though many options are shared with the C and C++ compilers. Fixes: #21561 Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
* CMakeDetermineCompilerId: Ensure CMAKE_EXECUTABLE_FORMAT is INTERNALCraig Scott2020-12-171-2/+2
| | | Fixes: #21607
* CMakeDetermineCompilerId: support Intel DPC++ compiler toolset for VS genNikita Sirgienko2020-12-061-3/+10
| | | | | | | | | | | | | 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
* Merge topic 'compiler-id-extra-text'Brad King2020-12-041-7/+16
|\ | | | | | | | | | | | | | | | | f25ac39dee CMakeDetermineCompilerId: Tolerate stray text around INFO strings 5cb66f17ca CMakeDetermineCompilerId: Add whitespace to clarify logic 1ee99104f7 CMakeDetermineCompilerId: Filter IAR-AVR format INFO strings earlier Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5570
| * CMakeDetermineCompilerId: Tolerate stray text around INFO stringsBrad King2020-12-031-0/+4
| | | | | | | | | | | | | | | | | | | | When cross-compiling with Xcode our compiler id test binary may be compiled with multiple architectures. The INFO strings should be identical and therefore de-duplicated. However, this can be broken by stray text that happens to sit immediately before or after an INFO string. Filter out such text so we can match clean INFO strings. Fixes: #21526
| * CMakeDetermineCompilerId: Add whitespace to clarify logicBrad King2020-12-031-1/+5
| | | | | | | | Also initialize a variable closer to its use.
| * CMakeDetermineCompilerId: Filter IAR-AVR format INFO strings earlierBrad King2020-12-031-6/+7
| | | | | | | | Remove the bytes between characters from the entire list at once.
| * Merge topic 'cuda_detect_vs_codegen' into release-3.19Brad King2020-11-251-4/+8
| |\ | | | | | | | | | | | | | | | | | | 20807a1882 CUDA: Fix user-set architectures during detection with Visual Studio Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5531
* | | Makefiles Generators: use compiler for dependencies generationMarc Chevrier2020-11-291-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | Merge topic 'cuda_detect_vs_codegen'Brad King2020-11-251-4/+8
|\ \ \ | |/ / |/| / | |/ | | | | | | 20807a1882 CUDA: Fix user-set architectures during detection with Visual Studio Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5531
| * CUDA: Fix user-set architectures during detection with Visual StudioRaul Tambre2020-11-251-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Xcode: Default to arm64 arch on Apple Silicon hosts during compiler idBrad King2020-11-121-1/+8
| | | | | | | | | | | | | | | | | | | | In commit b6c60f14b6 (macOS: Default to arm64 architecture on Apple Silicon hosts, 2020-09-28, v3.19.0-rc1~63^2) we forgot to update the compiler id architecture selection added by commit 26673bf480 (Xcode: Explicitly specify default native architecture on macOS, 2020-07-16, v3.18.1~20^2). Issue: #21425
* | 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
generated by cgit v0.12 at 2025-01-17 19:16:38 (GMT)