summaryrefslogtreecommitdiffstats
path: root/Modules/Platform
Commit message (Collapse)AuthorAgeFilesLines
* Merge topic 'nag-fortran-ninja'Brad King2024-04-161-3/+8
|\ | | | | | | | | | | | | | | | | | | 4af20bb794 NAG-Fortran: Do not repeat preprocessing with Ninja on Apple platforms 91bb8dd872 NAG-Fortran: Fix MODULE library creation on Apple platforms e056006116 NAG-Fortran: Tell the Ninja generator how to preprocess Fortran sources 765a611956 NAG-Fortran: Added initial default compilation flags Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !9407
| * NAG-Fortran: Do not repeat preprocessing with Ninja on Apple platformsSimon Maertens2024-04-151-3/+7
| | | | | | | | | | | | | | The Ninja generator uses separate preprocessing and compilation steps. Do not pass `-fpp` when compiling an already-preprocessed source. Issue: #25900
| * NAG-Fortran: Fix MODULE library creation on Apple platformsSimon Maertens2024-04-151-0/+1
| | | | | | | | | | Previously we passed `-bundle` to the NAG Fortran front-end, which does not support it. Pass it through to the linker instead.
| * Merge topic 'clang-windows-make-depends'Brad King2024-02-132-2/+2
| |\ | | | | | | | | | | | | | | | | | | 492f456c1c Clang: Fix typo to enable compiler-generated Makefile dependencies on Windows Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !9245
* | \ Merge topic 'swift-module-libraries'Brad King2024-04-162-0/+5
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | 56e5cea600 Swift: Support module libraries with command-line build systems Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !9379
| * | | Swift: Support module libraries with command-line build systemsEvan Wilde2024-04-152-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Wire up the flags needed to support module libraries built and used with Swift. We need to pass `-bundle` to the linker when linking module libraries on Darwin, and we need to pass `-export-dynamic` to the linker when emitting an executable that exports symbols on Linux. This patch wires up `CMAKE_SHARED_MODULE_CREATE_Swift_FLAGS` and `CMAKE_SHARED_MODULE_LOADER_Swift_FLAG` on Darwin, and hooks up `CMAKE_EXE_EXPORTS_Swift_FLAG` on Linux in order to support passing things correctly. We can't expose `CMAKE_EXE_LINKER_FLAGS` to Swift, as it contains flags that the Swift compiler doesn't recognize, but the other language-specific variables are safe to expose.
* | | | Merge topic 'aix-export-tdata'Brad King2024-04-121-1/+1
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | b4d1ab42b8 AIX: Consider tdata symbols in ExportImportList Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !9422
| * | | AIX: Consider tdata symbols in ExportImportListDavid Tenty2024-04-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Thread-local variables are put in the tdata section on AIX / XCOFF [1]. Unfortunately the ExportImportList script currently doesn't consider this section when looking for symbols to export. This results in linking failures in applications (such as LLVM) when building which expect these thread local variables to be exported from their shared libraries. [1]: https://www.ibm.com/docs/en/aix/7.3?topic=formats-xcoff-object-file-format
* | | | Merge topic 'artos-lib-prefix'Brad King2024-04-031-1/+1
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | e6b63b5cb2 ARTOS: Add support for finding library files named with 'lib' prefix Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: Bert Ezendam <bert.ezendam@alliander.com> Merge-request: !9399
| * | | | ARTOS: Add support for finding library files named with 'lib' prefixBrad King2024-04-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Update the platform module added by commit 462fbd1eca (Add support for ARTOS platform using GNU C with ac compiler driver, 2015-08-13, v3.4.0-rc1~201^2) to tell `find_library` to consider library file names starting in `lib`. FindEXPAT needs this on ARTOS since commit 13079f382b (FindEXPAT: Fix for debug and other modified builds, 2023-02-18, v3.27.0-rc1~463^2) removed its explicit `libexpat` library name candidate. Fixes: #25776
* | | | | Merge topic 'vs-intel-oneapi'Brad King2024-04-032-45/+34
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3f5cd0389f IntelLLVM: Fix link flags with Visual Studio generators Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !9398
| * | | | | IntelLLVM: Fix link flags with Visual Studio generatorsBrad King2024-04-022-45/+34
| |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The link flag wrapping added by commit 5d5a712303 (IntelLLVM: Pass linker flags to the compiler when used as linker, 2022-05-27, v3.25.0-rc1~344^2~4) is not needed with Visual Studio generators because MSBuild invokes the linker directly. Furthermore, that commit omitted wrapping of the per-config linker flags. Revise the logic to add the link flag wrapping more precisely. Fixes: #25533
* | | | | Merge topic 'swift-linker-selection'Brad King2024-04-033-0/+23
|\ \ \ \ \ | |_|/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | 3fb4092826 Swift: Add CMAKE_LINKER_TYPE support Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !9380
| * | | | Swift: Add CMAKE_LINKER_TYPE supportEvan Wilde2024-04-023-0/+23
| |/ / / | | | | | | | | | | | | | | | | | | | | Extend commit 96a953b1ed (Add options to specify linker tool, 2023-09-27, v3.29.0-rc1~577^2) with the `CMAKE_Swift_USING_LINKER_*` variables needed to support `CMAKE_LINKER_TYPE` for Swift.
* | | | Modules: Fix CMP0159 warnings in modules when tracingJuan Ramos2024-03-294-0/+12
| | | | | | | | | | | | | | | | Closes: #25829
* | | | OpenWatcom: Fix Windows3x DLL linkingJiri Malak2024-03-251-2/+2
|/ / / | | | | | | | | | Fix DLL creation for 16-bit Windows.
* | | LINKER_TYPE: Support MOLD only on GCC versions that support itMarc Chevrier2024-03-131-1/+4
| | | | | | | | | | | | Fixes: #25748
* | | Merge topic 'clang-windows-make-depends' into release-3.29Brad King2024-02-132-2/+2
|\ \ \ | |/ / |/| / | |/ | | | | | | 492f456c1c Clang: Fix typo to enable compiler-generated Makefile dependencies on Windows Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !9245
| * Clang: Fix typo to enable compiler-generated Makefile dependencies on WindowsBrad King2024-02-122-2/+2
| | | | | | | | | | Fix a typo from commit 2c71d051fa (Makefiles Generators: use compiler for dependencies generation, 2020-10-18, v3.20.0-rc1~392^2).
* | MinGW: Add support for OBJC and OBJCXXمهدي شينون (Mehdi Chinoune)2024-02-136-0/+42
|/
* Merge branch 'backport-3.28-visionOS' into visionOSBrad King2024-02-091-3/+3
|\
| * visionOS: Update deployment-target flag for Xcode 15.1 betaBrad King2024-02-091-3/+3
| | | | | | | | | | | | | | | | Use the same flags Xcode adds for `XROS_DEPLOYMENT_TARGET`. They are `-target arm64-apple-xros1.0` and `-target arm64-apple-xros1.0-simulator`, where `1.0` is the deployment target version. Fixes: #25188
* | CUDA/Clang: Fail early when mixing clang++ with cl on WindowsBrad King2024-01-311-13/+8
| | | | | | | | | | | | | | | | | | In commit 88c740462c (CUDA/Clang: Add support for MSVC ABI on Windows using GNU-like frontend, 2024-01-17) we updated the message for the existing check to mention CUDA, but neglected to update the check itself. Issue: #25648
* | Merge topic 'cuda-clang-windows'Brad King2024-01-232-2/+21
|\ \ | | | | | | | | | | | | | | | | | | | | | 88c740462c CUDA/Clang: Add support for MSVC ABI on Windows using GNU-like frontend Acked-by: Kitware Robot <kwrobot@kitware.com> Reviewed-by: Raul Tambre <raul@tambre.ee> Merge-request: !9172
| * | CUDA/Clang: Add support for MSVC ABI on Windows using GNU-like frontendBrad King2024-01-222-2/+21
| | | | | | | | | | | | Fixes: #20776
* | | MSVC: Teach find_library to consider the 'libfoo.a' naming conventionBrad King2024-01-191-1/+5
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When targeting the GNU ABI, we consider `.a` libraries first but also accept `.lib`. For symmetry, when targeting the MSVC ABI, we now consider `.lib` first but also accept `.a`. This adds support for meson-generated static libraries, which are named with the pattern `lib${foo}.a`: * https://mesonbuild.com/FAQ.html#why-does-building-my-project-with-msvc-output-static-libraries-called-libfooa Note that this was previously attempted by * commit be848a71b0 (MSVC: Teach find_library to consider the 'libfoo.a' naming convention, 2022-09-19, v3.25.0-rc1~111^2) but was reverted by * commit 955d6245c1 (MSVC: Revert "Teach find_library to consider the 'libfoo.a' naming convention", 2022-11-28, v3.25.1~6^2) due to problems finding GNU ABI libraries in PATH-derived prefixes. Since then, * commit 0a81110b84 (find_(library|file|path): Drop PATH-derived search prefixes, 2023-09-14, v3.28.0-rc1~91^2) removed the problematic search paths, so we can restore this change. Fixes: #23975
* | Merge topic 'compute-compiler-linker'Brad King2023-12-091-0/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | df025444b2 LinkerId: Identify AIX and SunOS system linkers c1e48a19a5 LinkerId: Try multiple flags to detect linker id and version 1e42a0cf18 LinkerId: Match linker id and version more robustly Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: buildbot <buildbot@kitware.com> Merge-request: !9057
| * | LinkerId: Identify AIX and SunOS system linkersBrad King2023-12-081-0/+1
| | | | | | | | | | | | Populate `CMAKE_<LANG>_COMPILER_LINKER_{ID,VERSION}` on these platforms.
* | | Merge topic 'LLVMFlang-Fortran-link-enhancements'Brad King2023-12-091-0/+1
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | 0502b345f2 LLVMFlang Fortran: enhance link capabilities Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !9025
| * | | LLVMFlang Fortran: enhance link capabilitiesMarc Chevrier2023-12-081-0/+1
| |/ / | | | | | | | | | | | | * Add support for "LINKER:" prefix. * Add support, on Linux, for linker selection through CMAKE_LINKER_TYPE variable.
* | | Merge topic 'find-rustc-importlibs'Brad King2023-12-091-1/+4
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | f20c5c6f20 MSVC: Teach find_library to consider Rust's '${name}.dll.lib' convention 7598ea5389 Tests: Add case covering find_library behavior when targeting MSVC ABI Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !9046
| * | MSVC: Teach find_library to consider Rust's '${name}.dll.lib' conventionDaniel Ching2023-12-081-1/+4
| | | | | | | | | | | | | | | | | | | | | This convention is used by Rust toolchains (rustc/cargo/cargo-c) for the MSVC ABI. Fixes: #25478
* | | LLVMFlang: Update MSVC runtime library selection for LLVMFlang 18.0Brad King2023-12-061-11/+16
|/ / | | | | | | | | | | | | | | | | LLVMFlang 18.0 adds MSVC runtime library selection flags and associated Fortran runtime library variants. Resolve the corresponding FIXME left by commit 26bf32cdc6 (LLVMFlang: Add support for targeting MSVC ABI on Windows, 2023-09-28, v3.28.0-rc1~10^2). Issue: #24840
* | Merge topic 'LLVMFlang-MSVC-debug'Brad King2023-12-061-5/+7
|\ \ | |/ | | | | | | | | | | ef49ed0fe1 LLVMFlang: Fix MSVC ABI debug information format options Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !9037
| * LLVMFlang: Fix MSVC ABI debug information format optionsBrad King2023-12-051-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | In commit 26bf32cdc6 (LLVMFlang: Add support for targeting MSVC ABI on Windows, 2023-09-28, v3.28.0-rc1~10^2) we incorrectly recorded `-g` as supporting the `ProgramDatabase` format, but it is actually `Embedded`, matching Clang. In order to support easy integration with C and C++ projects that use the `.pdb` debug formats, pretend LLVMFlang supports them and just don't actually emit any debug information. Issue: #24840
* | ADSP: Allow progress with CMAKE_ADSP_ROOT unsetJosh Channings2023-11-301-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a behavior change. You can still set ADSP_ROOT/CMAKE_ADSP_ROOT to hint the find_program() invocations for the CCES binaries, but it is no longer necessary if they are already in PATH. The reason is: CMAKE_ADSP_ROOT is only used to find the binaries. If they are in PATH, there is no need to supply the root path. If they are not in PATH, you can hint still hint it as before. The other option would be to use find_path() to get CMAKE_ADSP_ROOT from the path to one of the bins, but that would be convoluted and pointless. There are some circumstances where the binaries are available, but the ADSP install is not. For example, from my own dev environment: https://github.com/joshchngs/macos-sharc-tools Here, the `cc21k` et. al. binaries are actually shell scripts which launch the real binary inside a running VM.
* | ADSP: Add /opt/analog/cces to _find_adsp_root()'s search spaceJosh Channings2023-11-301-0/+3
| | | | | | | | This is the default install location on Linux.
* | ADSP: Use find_program() to get path to cc21k/ccblkfnJosh Channings2023-11-301-1/+6
| | | | | | | | | | | | This still uses CMAKE_ADSP_ROOT as the PATHS argument, so the same behavior should be retained - but now the Platform will work without needing to supply the root, if the binaries are already in $PATH.
* | ADSP: Use $CMAKE_EXECUTABLE_SUFFIX in COMPILER_NAMEJosh Channings2023-11-291-2/+2
| | | | | | | | The binaries are obviously not .exe-suffixed on Linux
* | Link step: Enable to configure deduplication of librariesMarc Chevrier2023-11-095-0/+9
| | | | | | | | | | | | | | | | | | Some platforms, Apple or Windows for instance, do not require to duplicate static libraries to resolve mutual dependencies. Moreover, Xcode version 15 emits a warning if a library is duplicated. On Windows, enable a better control of libraries order. Fixes: #20722, #25297
* | Genex LINK_LIBRARY: fix some definitions for Apple platformsMarc Chevrier2023-11-011-4/+4
| | | | | | | | | | | | | | | | Some declarations were inconsistent. For example, "LINKER:-force_load <LIBRARY>" was translated to "-Xlinker -force_load /path/to/library". The correct translation should be "-Xlinker -force_load -Xlinker /path/to/library" because the library is an argument to the -force_load option.
* | Link Step: compute effective linker used by the compilerMarc Chevrier2023-10-245-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extract the effective linker during the computation of implicit artifacts delivered by the compiler to the linker. Define various variables describing the linker: * CMAKE_<LANG>_COMPILER_LINKER * CMAKE_<LANG>_COMPILER_LINKER_VERSION * CMAKE_<LANG>_COMPILER_LINKER_ID * CMAKE_<LANG>_COMPILER_LINKER_FRONTEND_VARIANT This is complementary to feature introduced by commit 96a953b1ed (Add options to specify linker tool, 2023-09-27). Fixes: #17596, #18209, #25344
* | Add options to specify linker toolMarc Chevrier2023-10-139-2/+51
|/ | | | | | | | | | | | | | | | | | Offer the capability, through variable `CMAKE_LINKER_TYPE`, as well as the target property `LINKER_TYPE` to specify which linker must be used. The implementation of this capability is specified by variables specific to the language and linker type: `CMAKE_<LANG>_USING_LINKER_<TYPE>`. Some definitions are provided as part of `CMake`. For example, to select the `LLVM` linker rather than the standard one, the type `LLD` should be specified through the variable `CMAKE_LINKER_TYPE`. And, on `Apple`, `Linux` and some environments on `Windows`, the variable `CMAKE_<LANG>_USING_LINKER_LLD` has value `-fuse-ld=lld`. And for `Windows` environments based on `MSVC`, where the linker is used directly, the tool `lld-link.exe` will be used rather than `link.exe`. Fixes: #19174, #24254, #24990
* LLVMFlang: Add support for targeting MSVC ABI on WindowsBrad King2023-10-031-3/+58
| | | | | | | | | | The compiler does not yet support everything needed to integrate well with the MSVC ABI, in particular for runtime library selection and debug format selection. Document them in FIXME comments and leave this support undocumented by CMake for now. Fixes: #24840 Inspired-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
* OrangeC: Add support for OrangeC compilerDavid Lindauer2023-09-253-0/+14
| | | | | | | Add compiler information modules. Update the test suite. Fixes: #25032 Co-authored-by: Brad King <brad.king@kitware.com>
* macOS: Framework: simplify link flagMarc Chevrier2023-09-212-0/+7
| | | | Use the compiler option rather than the linker one.
* MinGW: Search for packages in standard MSYSTEM environment prefixesBrad King2023-09-131-0/+19
| | | | | | | | | | | | | | | | MSYS2 and similar MinGW/MSYS distributions define development environments with a `MSYSTEM` environment variable. Each such environment has a documented installation prefix for its packages, often provided by a `MSYSTEM_PREFIX` environment variable. Since commit 84a25fc263 (cmake_host_system_information: Add MSYSTEM_PREFIX query, 2023-09-08) we can look up this prefix. Add `$MSYSTEM_PREFIX/local` and `$MSYSTEM_PREFIX` to our system search prefixes when targeting MinGW under `MSYSTEM` environments. This is their equivalent to `/usr/local` and `/usr`, which we search by default on UNIX systems. Issue: #24216
* Windows: Add experimental WindowsKernelModeDriver platformKyle Edwards2023-07-176-3/+41
|
* Merge topic 'android-platform'Brad King2023-07-141-0/+2
|\ | | | | | | | | | | | | bfe4722a61 Android: Restore platform info and search paths shared with Linux Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !8626
| * Android: Restore platform info and search paths shared with LinuxBrad King2023-07-131-0/+2
| | | | | | | | | | | | | | | | These were accidentally dropped by commit 1373373823 (enable_language: Establish target platform identification variables earlier, 2023-06-06, v3.27.0-rc1~3^2~1). Fixes: #25077
generated by cgit v0.12 at 2025-03-27 20:18:32 (GMT)