summaryrefslogtreecommitdiffstats
path: root/Modules/Platform
Commit message (Collapse)AuthorAgeFilesLines
* Modules: Fix typos and spelling in commentsJosef Angstenberger2021-05-071-1/+1
|
* Merge topic 'clang-ipo-support'Brad King2021-05-051-2/+2
|\ | | | | | | | | | | | | 3dd776ccfd Windows-Clang: Support duplicate object names in LTO archives Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !6082
| * Windows-Clang: Support duplicate object names in LTO archivesBrad King2021-05-031-2/+2
| | | | | | | | | | | | | | | | | | Update the archive rules added by commit 6e3655db2c (Clang: add LTO support for GNU-command line clang on windows, 2019-07-08, v3.16.0-rc1~161^2~3) to match the `ar` convention we use for normal archives. Issue: #21988
* | Windows-GNU: Support duplicate object names when linking shared librariesBrad King2021-05-031-1/+1
|/ | | | | | | | | Extend the change from commit 39d0ade07e (Windows-GNU: Support duplicate object names in large archives (#14874), 2014-04-14, v3.1.0-rc1~629^2~1) to apply to the temporary archive we create for linking shared libraries with MinGW tools. Issue: #21988
* MSYS: Add support for running under MSYS runtime environmentOrgad Shaneh2021-04-2610-2/+14
| | | | Detect MSYS as CYGWIN, with the required adaptations.
* Merge topic 'ios-rpath-linker-flag'Brad King2021-04-071-5/+1
|\ | | | | | | | | | | | | 4aed96e230 Apple: Set CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG on non-macOS too Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5980
| * Apple: Set CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG on non-macOS tooCraig Scott2021-04-061-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since CMake 3.19, we no longer support macOS SDKs older than 10.5, which corresponds to Xcode 3. Supporting older Xcode versions for device platforms is also not realistic. We therefore expect the -rpath linker option should always be supported now. When targeting iOS, tvOS or watchOS, the previous disabling of -rpath support meant that the install_name_dir of shared libraries and frameworks was unable to use @rpath. This resulted in embedding absolute paths for their install_name. When they were embedded in an app bundle, this would cause the app to fail at runtime. By enabling the -rpath linker option, the default install_name_dir is now @rpath for these platforms, which results in binaries that do work at runtime. Fixes: #20036
* | Merge topic 'nvhpc-lib-arch'Brad King2021-04-061-1/+0
|\ \ | | | | | | | | | | | | | | | | | | | | | 764606e256 CMakeDetermineCompilerABI: Extract lib arch from implicit object file paths 5d44d73bbe CMakeDetermineCompilerABI: Revert "Parse library arch from versioned paths" Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5984
| * | CMakeDetermineCompilerABI: Revert "Parse library arch from versioned paths"Robert Maynard2021-04-051-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The change in commit 657fc3a9a7 (CMakeDetermineCompilerABI: Parse library arch from versioned paths, 2021-02-03, v3.20.0-rc1~40^2) caused `CMAKE_LIBRARY_ARCHITECTURE` to be populated on non-multiarch platforms if their compilers happen to use `$arch/$version` library directories. Revert the use of versioned library paths. Fixes: #22024
* | | Merge topic 'fujitsu-compiler-4.0-support'Brad King2021-04-013-0/+19
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 8ef55dec29 Help: Add release notes for Fujitsu compiler support 4c74c86f40 FindBLAS/LAPACK: Add support for the Fujitsu SSL2 library 376c300b25 FindOpenMP: Add support for Fujitsu compilers 9e0a1cf03e FindMPI: Add support for the Fujitsu compiler wrappers a237450948 Tests: Update for the FujitsuClang compiler 27579e9cf1 FujitsuClang: Add support for the Fujitsu compiler in Clang mode a55feff69c Tests: Update for the Fujitsu compiler 3c867cff4a Fujitsu: Add support for the Fujitsu compiler in Trad mode Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: Axel Huebl <axel.huebl@plasma.ninja> Acked-by: Gilles Gouaillardet <gilles@rist.or.jp> Merge-request: !5954
| * | | FujitsuClang: Add support for the Fujitsu compiler in Clang modeChuck Atkins2021-03-312-8/+2
| | | | | | | | | | | | | | | | | | | | | | | | This should be front end compatible with vanilla clang but giving it a unique identifier allows a project to pass additional options unique to Fujitsu and outside the scope of a CMake builtin.
| * | | Fujitsu: Add support for the Fujitsu compiler in Trad modeChuck Atkins2021-03-302-0/+25
| | | | | | | | | | | | | | | | Co-Author: Yuichiro Utsumi <utsumi.yuichiro@jp.fujitsu.com>
* | | | Merge topic 'android-binutils'Brad King2021-03-312-50/+50
|\ \ \ \ | |/ / / |/| | / | | |/ | |/| | | | | | | 61e6fc26bc Android: Fix search for binutils Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5958
| * | Android: Fix search for binutilsHaibo Huang2021-03-302-50/+50
| |/ | | | | | | | | | | | | | | Set `CMAKE_SYSTEM_PROGRAM_PATH` in `Platform/Android-Initialize` instead of `Platform/Android` so it can be used in `CMakeFindBinUtils`. Also add the names `llvm-strip` and `llvm-ranlib` for the corresponding tools.
* | Per-language Win32/Console flagsRaul Tambre2021-03-179-17/+24
| | | | | | | | | | | | | | | | Allows using different compilers with different flags for different languages. For example Clang with GNU-like commandline for CXX and MSVC as host compiler for CUDA. Should help with #21914.
* | Merge topic 'android-r22'Brad King2021-03-031-0/+39
|\ \ | |/ | | | | | | | | | | | | | | | | 005e2cdfb0 Android: Do not use gold for ndk >= r22 ed7a87f270 Tests: Update RunCMake.Android for NDK r22 4950d35733 Help: Document CMAKE_ANDROID_NDK_VERSION variable 746906242d Android: Detect NDK version number Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5862
| * Android: Detect NDK version numberHaibo Huang2021-03-031-0/+39
| | | | | | | | Report it in `CMAKE_ANDROID_NDK_VERSION`.
* | Platform/Windows-NVIDIA-CUDA: Remove duplicated codeRaul Tambre2021-02-141-9/+1
| | | | | | | | | | | | Some of the things are set in Platform/NVIDIA-CUDA and since we aren't setting them to different values there's no point in overriding them. Also fixed an unset() copy-paste error.
* | CUDA: Fix spelling __IMPLICT_ -> __IMPLICIT_Raul Tambre2021-02-142-22/+22
|/
* Merge topic 'clang-imsvc'Brad King2021-02-101-0/+1
|\ | | | | | | | | | | | | | | 2fc5e5dba9 Clang: Use -imsvc for system include only with MSVC-like front-end Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: Thomas Bernard <thomas@famillebernardgouriou.fr> Merge-request: !5792
| * Clang: Use -imsvc for system include only with MSVC-like front-endBrad King2021-02-091-0/+1
| | | | | | | | | | | | | | | | | | | | In commit bb61c2d024 (Clang: use -imsvc for system include dirs when running on Windows, 2020-09-16, v3.19.0-rc1~162^2) we added `-imsvc` for all Clang compilers targeting the MSVC ABI. However, the option only exists for the MSVC-like front-end. The GNU-like front-ends use `-isystem`. Fixes: #21789
* | CMakeDetermineCompilerABI: Parse library arch from versioned pathsRobert Maynard2021-02-041-0/+1
| | | | | | | | | | | | Teach CMake how to extract `CMAKE_<LANG>_LIBRARY_ARCHITECTURE` from versioned paths such as `/usr/lib/gcc/x86_64-linux-gnu/9`. These kind of paths are generated by NVHPC compilers.
* | IntelLLVM: Add support for Intel LLVM-based compilersWilliam R. Dieter2021-01-2813-0/+162
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | NVHPC: Add support for NVIDIA HPC SDK compilers based on PGITin Huynh2021-01-274-0/+21
| | | | | | | | | | | | | | Identify the compilers as `NVHPC` to distinguish it from the older PGI compilers from which they evolved, and from other `NVIDIA` compilers. Fixes: #20887
* | Merge topic 'intel-fortran-nofor-main'Brad King2021-01-251-1/+1
|\ \ | |/ | | | | | | | | | | 2a5955ac09 Intel: Replace deprecated Fortran flag -nofor_main with -nofor-main Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5729
| * Intel: Replace deprecated Fortran flag -nofor_main with -nofor-mainBrad King2021-01-221-1/+1
| | | | | | | | | | | | | | | | | | | | The `-nofor_main` flag was originally added by commit ccdd3e943d (Fix Intel Fortran SHARED libraries on Linux, 2009-10-27, v2.8.2~915). Since then, Intel Fortran renamed the option to `-nofor-main` and deprecated the old name. The new name has been available for a long time, so we can just switch to it. Fixes: #21735
* | Merge topic 'msvc-arm64ec-platform-support'Brad King2021-01-221-3/+15
|\ \ | | | | | | | | | | | | | | | | | | 4ea3a88625 MSVC: Add support for targeting ARM64EC Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5708
| * | MSVC: Add support for targeting ARM64ECMoyo Okeremi 😊2021-01-211-3/+15
| | |
* | | Clang: Support WIN32_EXECUTABLERaul Tambre2020-12-231-0/+3
|/ / | | | | | | Fixes #21613.
* | Merge topic 'macos-homebrew-apple-silicon'Brad King2020-12-141-0/+7
|\ \ | |/ | | | | | | | | | | | | 1a5c1a68b6 macOS: Add /opt/homebrew to CMAKE_SYSTEM_PREFIX_PATH on Apple Silicon Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: Fons Rademakers <fons.rademakers@cern.ch> Merge-request: !5602
| * macOS: Add /opt/homebrew to CMAKE_SYSTEM_PREFIX_PATH on Apple SiliconBrad King2020-12-111-0/+7
| | | | | | | | | | | | | | According to https://brew.sh/2020/12/01/homebrew-2.6.0/ the `/opt/homebrew` directory is recommended for installing ARM architecture brew packages. Fixes: #21585
* | Merge topic 'apple-silicon-host-arch'Brad King2020-12-111-4/+13
|\ \ | |/ | | | | | | | | | | | | b7f0327dcd Tests: Cover macOS host architecture selection on Apple Silicon hosts 5f882f6ce5 macOS: Offer control over host architecture on Apple Silicon hosts Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5589
| * macOS: Offer control over host architecture on Apple Silicon hostsBrad King2020-12-101-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit b6c60f14b6 (macOS: Default to arm64 architecture on Apple Silicon hosts, 2020-09-28, v3.19.0-rc1~63^2) we use `sysctl` to detect that we are running on Apple Silicon in a way that pierces Rosetta. This always sets `CMAKE_HOST_SYSTEM_PROCESSOR` to be `arm64` on such hosts. However, macOS offers strong support for running processes under an emulated `x86_64` architecture. Teach CMake to select either `arm64` or `x86_64` as the host architecture on Apple Silicon based on the architecture of its own process. When CMake is built as a universal binary, macOS will select whichever slice (architecture) is appropriate under the user's shell, and `CMAKE_HOST_SYSTEM_PROCESSOR` will match. Also offer a `CMAKE_APPLE_SILICON_PROCESSOR` variable and environment variable to provide users with explicit control over the host architecture selection regardless of CMake's own architecture. Finally, if `CMAKE_OSX_ARCHITECTURES` is not set, pass explicit flags to the toolchain to use selected host architecture instead of letting the toolchain pick. Fixes: #21554
* | Merge topic 'explicit-LANGUAGE-flag'Brad King2020-12-041-4/+4
|\ \ | | | | | | | | | | | | | | | | | | | | | 48aac247e9 Compile with explicit language flag when source LANGUAGE property is set 2e67a75acd Embarcadero: Simplify addition of -P flag for C++ Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5522
| * | Embarcadero: Simplify addition of -P flag for C++Brad King2020-12-021-4/+4
| | |
* | | Merge topic 'llvm-rc-preprocess-as-c'Brad King2020-12-031-5/+5
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | bdfa5ac7f6 Merge branch 'master' into llvm-rc-preprocess-as-c f7ff0d34f0 llvm-rc: Force C language for the clang gnu frontend Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5564
| * \ \ Merge branch 'master' into llvm-rc-preprocess-as-cBrad King2020-12-0222-94/+323
| |\ \ \ | | |_|/ | |/| |
| * | | llvm-rc: Force C language for the clang gnu frontendThomas Bernard2020-12-021-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When preprocessing the rc file using the clang gnu front end we need to force the source file type to a c file for the preprocessing to take place. Fixes: #21472
* | | | Merge topic 'ninja-deps-updates'Brad King2020-12-024-7/+52
|\ \ \ \ | |_|/ / |/| | | | | | | | | | | | | | | | | | | f8d8faff8d Ninja Generators: Homogenize configuration with Makefiles Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5557
| * | | Ninja Generators: Homogenize configuration with MakefilesMarc Chevrier2020-12-014-7/+52
| | |/ | |/| | | | | | | | | | * Use same configuration variables to configure dependencies * Abstract Ninja deps format from compiler one
* | | Merge topic 'windows-clang-LINKER-prefix'Brad King2020-12-011-0/+3
|\ \ \ | |/ / |/| / | |/ | | | | | | 9ac9876757 Clang on Windows: 'LINKER:' prefix must be honored Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5551
| * Clang on Windows: 'LINKER:' prefix must be honoredMarc Chevrier2020-11-301-0/+3
| | | | | | | | Fixes: #21094
* | Makefiles Generators: use compiler for dependencies generationMarc Chevrier2020-11-297-0/+67
| | | | | | | | | | | | | | | | | | | | | | 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
* | Refactoring: Introduce place-holder for dependency target.Marc Chevrier2020-11-283-4/+4
| | | | | | | | | | | | | | | | These changes are in preparation of compiler generated dependencies support for Makefiles generators * compiler output and dependency target can be different for Makefiles generators * resolve inconsistency naming for dependency file place-holder
* | MSVC: Do not add /GR to CMAKE_CXX_FLAGS by defaultBrad King2020-11-131-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | The `/GR` flag has been on by default since MSVC cl 14.0 from VS 2005. Remove it from the default flags to make it easier for projects to pass `/GR-` themselves to turn it off. Projects may be using string processing to replace `/GR` with another flag, so we cannot simply drop it. Add a policy to drop it in a compatible way. Fixes: #21428
* | MSVC: Factor out initialization of /GR flagBrad King2020-11-131-4/+8
| |
* | Android: load ABI information from abis.cmakeHaibo Huang2020-11-121-61/+76
| | | | | | | | | | They are added to NDK and planned to release in r23: https://android-review.googlesource.com/c/platform/ndk/+/1493421
* | Merge topic 'android-abi'Brad King2020-11-111-4/+13
|\ \ | |/ | | | | | | | | | | a585b75df9 Android: Use NDK_KNOWN_DEVICE_ABI{32,64}S instead of NDK_DEFAULT_ABIS Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5488
| * Android: Use NDK_KNOWN_DEVICE_ABI{32,64}S instead of NDK_DEFAULT_ABISHaibo Huang2020-11-101-4/+13
| | | | | | | | | | | | | | | | | | | | Revise logic from commit 1ab574a0f4 (Android: Add support for NDK r22, 2020-10-07, v3.19.0-rc1~18^2) that loads ABI tables from the NDK. `NDK_DEFAULT_ABIS` means the abis to build by default. Use `NDK_KNOWN_DEVICE_ABI{32,64}S` instead. In practise they have never been different. Fix to make it more precise.
* | Merge topic 'android-root'Brad King2020-11-101-32/+14
|\ \ | | | | | | | | | | | | | | | | | | | | | cbc51a8be3 Android: restructure android search paths Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: huangqinjin <huangqinjin@gmail.com> Merge-request: !5479