summaryrefslogtreecommitdiffstats
path: root/Modules/CMakeSwiftInformation.cmake
Commit message (Collapse)AuthorAgeFilesLines
* Swift: fix Windows DLL import library support for CMP0157 NEWSaleem Abdulrasool2024-01-101-1/+1
| | | | | | | This was accidentally removed when the command templates were reorganized to introduce the new policy. Restore the flag in the shared library creation to ensure that we emit the import libraries to the correct location.
* Swift/Ninja: Add support for response filesEvan Wilde2024-01-081-0/+1
| | | | | | | Adding support for `CMAKE_NINJA_FORCE_RESPONSE_FILE` with Swift. Issue: #25490 Fixes: #25563
* Swift/Ninja: Split compilation modelEvan Wilde2023-12-151-21/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Splitting the Swift build into an object build and a separate link step, instead of building and linking in one step. The immediate benefit is LSP support because we are able to emit compile-commands for Swift files now. Additionally, it is possible to specify flags to the compile step, enabling folks to emit C and C++ headers from their Swift builds for C/C++ interop, without needing custom commands. Eventually, this gives us a path toward working object libraries. Object Libraries: - Object libraries don't work today because CMake doesn't emit targets for object libraries into the Ninja build file. - tl;dr: Object libraries work if they aren't WMO. Still need work to make WMO'd object libraries work. Object libraries still don't completely work with this patch because, while we emit the targets, the `TARGET_OBJECTS` generator expression expansion has a separate mechanism for determining what the names of the objects are based on the input source files, so targets that depend on an object library built with a whole-module optimization will depend on objects based on the name of the source file instead of the actual emitted object file. These features require being able to accurately model wholemodule builds though, because we actually need to track object files and WMO affects what objects are emitted. For that, we require CMP0157 use the NEW policy. When it's OLD, we have to fall back on the old behavior and cannot provide object libraries or the compile-commands for LSP. Issue: #25308
* Swift: Add abstraction for compilation modeEvan Wilde2023-11-171-17/+29
| | | | | | | | | | | Add a `CMAKE_Swift_COMPILATION_MODE` variable and corresponding `Swift_COMPILATION_MODE` target property to control the compilation mode. Select among `wholemodule`, `singlefile`, and `incremental`. Add policy CMP0157 to remove the default `-wmo` flags in favor of the abstract setting. Issue: #25366
* apple: add preliminary visionOS supportGregor Jasny2023-07-111-2/+4
|
* Merge topic 'swift-old-driver'Brad King2023-03-291-3/+11
|\ | | | | | | | | | | | | 006e1995eb Swift: Restore compatibility with old C++ driver Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !8365
| * Swift: Restore compatibility with old C++ driverYR Chen2023-03-281-3/+11
| | | | | | | | | | | | | | | | | | The `-wmo` flag added by commit 6063428de7 (Swift: Update default build flags, 2022-10-03, v3.26.0-rc1~585^2~1) behaves differently with the old driver. Detect when the old driver is being used, and avoid adding that flag. Fixes: #24641
* | Swift: Emit debug information on WindowsSaleem Abdulrasool2023-02-161-2/+2
|/ | | | | | | | | When building on Windows, pass `-debug` to the linker to emit the PDB (or `-debug:dwarf` when building with lld and using DWARF). We would previously not do this which meant that we never emitted the debug information making debugging more difficult. Fixes: #24423
* Merge topic 'ninja-swift-exported-executables'Brad King2023-01-201-2/+4
|\ | | | | | | | | | | | | 4165eb3d0b Ninja: Emit swiftmodule from executable with exports Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !8048
| * Ninja: Emit swiftmodule from executable with exportsEvan Wilde2023-01-191-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for tracking the swiftmodules for executables exporting symbols. This fixes a bug in the earlier implementation around emitting the swiftmodule. Previously, the code would use `CMAKE_EXE_EXPORTS_Swift_FLAG` to inject the `-emit-module`, and module path information into the `CMAKE_Swift_LINK_EXECUTABLE` rule. Because Swift skips the build step and only runs during the link phase, these flags were injected in `cmNinjaNormalTargetGenerator::ComputeLinkCmd` instead of `cmLocalGenerator::GetTargetFlags` where it is done normally. Unfortunately, injecting in `ComputeLinkCmd` didn't do anything because we have a `linkCmd` so `ComputeLinkCmd` exits early, before the EXE_EXPORT flags get added to the link command. Instead of playing with that flag, CMake checks `CMAKE_Swift_LINK_EXECUTABLE_WITH_EXPORTS` and uses that as the link rule if it exists and falls back on `CMAKE_Swift_LINK_EXECUTABLE`. I've defined that variable in terms of `CMAKE_Swift_LINK_EXECUTABLE` with the necessary additional flags for emitting the swift module instead. This has the same end effect as the desired behavior, but simplifies things a bit. Since we're generating the swiftmodule for executables with exports, I've also updated the dependency graph to include the swiftmodule as an output in the build dependency graph if the executable has exports. Tests updated: - RunCMake/NoWorkToDo: Ensure that the build graph does not result in unnecessary rebuilds with exporting executables. - SwiftOnly: Ensure that we can consume functions defined in the executable by a library getting linked into said executable.
* | Swift: Add comment about where platform-specific flags should goBrad King2023-01-171-1/+2
| |
* | Swift: Use macOS-style linker flags on iOS, tvOS, and watchOS tooCraig Hutchinson2023-01-171-2/+4
|/ | | | | | Without this, building a shared Swift library with `CMAKE_SYSTEM_NAME=iOS` produces the error `ld: unknown option: -soname`. iOS is an Apple platform, and so should use the `-install_name` option.
* Swift: Omit output-file-map when used as a linkerEvan Wilde2022-10-281-3/+3
| | | | | | | | | | | | | | | Swift is used as the linker for non-swift files because it needs to pull files like swiftrt.o in when swift symbols are present to ensure that the swift runtime is linked. The swift driver uses clang as the underlying linker, which pulls in crtbegin.o and friends when appropriate, so using Swift as a linker for C/C++ libraries is fine. The output-file-map was getting passed to all Swift invocations, regardless of whether or not we generated one. This patch changes it so that we only include the output-file-map in the Swift compiler invocation if we have actually generated the file.
* Swift: Update default build flagsEvan Wilde2022-10-111-7/+19
| | | | | | | | | | | | | | | | | | | | Fully-optimized builds should be using whole-module optimizations(WMO) to get all the optimizations the compiler can do for a given module. As such, it makes sense for the release builds to pass `-whole-module-optimization` or `-wmo` to the compiler by default. `-whole-module-optimization` and `-wmo` are aliased and have the same impact on the build. Removing `-incrementa' from the `CMAKE_Swift_CREATE_*` variable: WMO is incompatible with incremental builds, so it is removed to avoid warnings from the Swift compiler. Pass `-num-threads` to the driver in `CMAKE_Swift_CREATE_*`: WMO doesn't use the `-j` flag, but instead uses `-num-threads` to get parallelism. The two flags are applied in mutually exclusive contexts, so `-j N` is a no-op in WMO, while `-num-threads` is a no-op in other modes. Passing both at the same time will catch both cases without negatively impacting the other case.
* Swift: Disable optimization when compiling in DebugDavid Geldreich2022-08-041-1/+1
| | | | | | | | | By default no `-O...` flag is specified for Debug configuration for Swift so Xcode adds a (wrong) `-O` flag that prevents one from accessing variables while debugging. Add `-Onone` to the Swift Debug configuration to avoid this. Fixes: #23818
* LINK_WHAT_YOU_USE feature: externalize configurationMarc Chevrier2021-07-091-0/+9
| | | | | | | | Currently, this feature is only supported on ELF platforms. So, the property LINK_WHAT_YOU_USE will be ignored for other plateforms. Moreover, flags and commands are now controled by CMake variables. Fixes: #20174
* Swift: repair RPATH handling for macOSSaleem Abdulrasool2020-03-111-4/+6
| | | | | | | | The configuration previously handled Linux properly but did not function on macOS as `ld64` does not support `:` delimited paths. Account for that by setting it to the empty string which will use multiple invocations of the `-Xlinker -rpath -Xlinker ...` pattern to compute the correct RPATH.
* Swift: support `-rpath` for executablesSaleem Abdulrasool2020-02-171-0/+5
| | | | This adjusts the flags to enable setting the RPATH for executables.
* Ninja: properly handle exports from Swift exesSaleem Abdulrasool2020-02-021-1/+3
| | | | | | This adds logic to properly handle Swift executables. Only executables marked as exporting symbols will now generate module interfaces for the executable.
* Swift: move windows handling into platform file (NFC)Saleem Abdulrasool2019-12-221-4/+0
| | | | | | | This moves the definition of the import library flags for Windows into a platform specific file (much like the Darwin `-sdk` flag). This is in preparation for re-use of the flag to make the flags handling for executables more precise.
* Merge topic 'swift-rpath-darwin'Brad King2019-11-181-1/+1
|\ | | | | | | | | | | | | ff6c336127 Swift: support `-rpath` on Darwin Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !4059
| * Swift: support `-rpath` on DarwinSaleem Abdulrasool2019-11-181-1/+1
| | | | | | | | | | | | | | | | | | Darwin also has the concept of RPATH. Additionally, the flag is identical to that on other Unixish platforms. Simply avoid the `-rpath` handling on Windows. This enables the use of `BUILD_WITH_INSTALL_RPATH` and `INSTALL_RPATH` with Swift targets on Darwin.
* | Merge topic 'swift-darwin-install-name'Brad King2019-11-181-1/+1
|\ \ | |/ |/| | | | | | | | | f935de6746 Swift: support `INSTALL_NAME_DIR` on Darwin Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !4060
| * Swift: support `INSTALL_NAME_DIR` on DarwinSaleem Abdulrasool2019-11-181-1/+1
| | | | | | | | | | | | | | Adjust the shared object rule to ensure that we honour the `INSTALL_NAME_DIR` property on Swift targets. This enables the use of `INSTALL_NAME_DIR` and `BUILD_WITH_INSTALL_NAME_DIR` on Darwin with Ninja.
* | Swift: Allow build and installed RPATHs to differSaleem Abdulrasool2019-11-121-0/+1
|/ | | | | | Define the RPATH separator to `:` so that CMake can reserve room to edit the ELF RPATH at install time. This enables the use of `BUILD_RPATH` and `INSTALL_RPATH` with differing values.
* Merge branch 'swift-rpath' into release-3.16Brad King2019-10-311-0/+4
|\ | | | | | | Merge-request: !3965
| * Swift: support `BUILD_RPATH` propertiesSaleem Abdulrasool2019-10-301-0/+4
| | | | | | | | | | Enable passing a RPATH to Swift shared libraries. This enables testing libraries before they have been installed.
* | Swift: correct flags for parallel jobsSaleem Abdulrasool2019-10-281-3/+3
|/ | | | | | | `-num-threads` is for the threading, not the job control. Use `-j` to launch the parallel jobs. This enables parallel builds for Swift again after driver updates preventing the parallelization through `-num-threads`.
* Merge topic 'swift-mode-flags'Brad King2019-08-191-0/+2
|\ | | | | | | | | | | | | | | 4d83e47c05 Swift: define `CMAKE_Swift_FLAGS` correctly Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: Ben Boeckel <ben.boeckel@kitware.com> Merge-request: !3684
| * Swift: define `CMAKE_Swift_FLAGS` correctlySaleem Abdulrasool2019-08-121-0/+2
| | | | | | | | | | Invoke `cmake_initialize_per_config_variable` to ensure that build type flags are properly initialised.
* | Merge topic 'swift-import-library-location'Kyle Edwards2019-08-191-2/+6
|\ \ | | | | | | | | | | | | | | | | | | | | | 5480f65ab1 Swift: honour `IMPLIB_LOCATION` property Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: Ben Boeckel <ben.boeckel@kitware.com> Merge-request: !3686
| * | Swift: honour `IMPLIB_LOCATION` propertySaleem Abdulrasool2019-08-121-2/+6
| |/ | | | | | | | | | | | | | | The rules did not account for the import library location (through `<TARGET_IMPLB>`) and instead would always write the import library to the default location (next to the shared library/executable). This prevented the use of `CMAKE_RUNTIME_OUTPUT_LOCATION` and `CMAKE_ARCHIVE_OUTPUT_LOCATION`.
* | Generator: support per-language link library flagSaleem Abdulrasool2019-08-091-0/+1
|/ | | | | | | | This enables the use of MSVC and Swift on Windows in a single project. MSVC uses no flag to indicate linked libraries while Swift uses `-l`. Add support for a language specific link library flag which takes precedence over the global `CMAKE_LINK_LIBRARY_FLAG` which preserves compatibility with earlier releases.
* Swift: correct SONAME flag for Darwin targetsSaleem Abdulrasool2019-08-061-1/+3
| | | | Adjust the build rules for Swift to fix the SONAME handling for Darwin.
* Swift: refactor rule construction to reduce duplicationSaleem Abdulrasool2019-07-171-16/+10
| | | | | | Use the placeholder expansion to avoid constructing the `-target` option by hand if specified. This reduces duplication and simplifies the rules.
* Swift: support SONAME on ELFish targetsSaleem Abdulrasool2019-07-111-2/+5
| | | | | | We should enable the soname to be setup for ELF shared libraries. Failure to do so generates binaries with incorrect names which prevents loading.
* Swift: support multithreaded compilationSaleem Abdulrasool2019-07-021-6/+10
| | | | | Query the number of logical CPUs available to enable parallel compilation for Swift.
* Swift: add rules for static linkingSaleem Abdulrasool2019-06-281-0/+6
| | | | | | The Swift driver recently learnt how to generate static libraries using the `-static` flag. This enables us to generate proper static libraries with dependency tracking with Swift as well.
* Support per-language library link flagsSaleem Abdulrasool2019-06-061-0/+2
| | | | | | | | | | This changes the behaviour of the generators to use a per-language library search path flag. This is needed for multi-language projects with different compilers (e.g. cl + gfortran). Since the adjusted variable has been part of the user settings, we control this based on a policy. Fixes: #19307
* Merge topic 'swift-wrapper'Brad King2019-05-291-1/+2
|\ | | | | | | | | | | | | 6baa80d1e3 Modules: correct linker wrapper flag for Swift Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !3390
| * Modules: correct linker wrapper flag for SwiftSaleem Abdulrasool2019-05-281-1/+2
| | | | | | | | | | This was sitting locally but was missed in previous commits. This enables the use of `LINKER:` when building Swift code bases.
* | Merge topic 'linker-preference'Brad King2019-05-291-0/+3
|\ \ | |/ |/| | | | | | | | | abea06efdf Modules: setup `CMAKE_Swift_LINKER_PREFERENCE` Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !3373
| * Modules: setup `CMAKE_Swift_LINKER_PREFERENCE`Saleem Abdulrasool2019-05-241-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | Swift's driver will invoke the C++ driver (`clang++`) to invoke the linker. Additionally, it will configure the command line to deal with the linkage runtime support object (`swiftrt.o` or `swiftrt.obj`) to be added at the right time (similar to C/C++). Since it indirects through `clang++` it will properly setup the linker invocation for C++ and C as well. This should permit the correct linker driver to be invoked in multi-language projects. Closes #19299
* | Ninja,Swift: correct response file handlingSaleem Abdulrasool2019-05-231-0/+2
|/ | | | | | | | The response file was being written but not used due to the wrong variable being configured for Swift. Swift does compile+link in a single phase and does not use the `<OBJECTS>` placeholder. Use the `<SWIFT_SOURCES>` placeholder instead for the response file substitution which serves the same purpose.
* Merge topic 'swift-flag-variables'Brad King2019-05-231-2/+10
|\ | | | | | | | | | | | | | | | | 24223ac84b Modules: add Swift MSVC_RUNTIME_LIBRARY flags 7e636fd8e0 Modules: add `CMAKE_Swift_FRAMEWORK_SEARCH_FLAG` 0fbf936b46 Modules: remove `CMAKE_INCLUDE_FLAG_SEP_Swift` Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !3353
| * Modules: add Swift MSVC_RUNTIME_LIBRARY flagsSaleem Abdulrasool2019-05-211-0/+8
| | | | | | | | | | | | This adds support for the newly minted `-libc` flag to the Swift driver invocation. These allow users to control the MSVC linkage properly on Windows targets.
| * Modules: add `CMAKE_Swift_FRAMEWORK_SEARCH_FLAG`Saleem Abdulrasool2019-05-211-0/+1
| | | | | | | | | | | | Swift supports frameworks and uses them across all OSes. They are added using the `-F` flag. There must be a space following the flag and before the parameter.
| * Modules: remove `CMAKE_INCLUDE_FLAG_SEP_Swift`Saleem Abdulrasool2019-05-211-2/+1
| | | | | | | | | | | | The include flag specifier should be specified multiply. The separator was being misused for adding a space after the `-I` flag. Correct this to get multiple include paths correct.
* | Ninja,Swift: pass along DEFINES/FLAGS/INCLUDESSaleem Abdulrasool2019-05-211-4/+4
|/ | | | | | | Since the Swift model does a single compile/link phase, we would not get the compile definitions, includes, and options past along to the build of the module. Compute these for the target when constructing the main command.
* Modules: add build rules for Swift Ninja supportSaleem Abdulrasool2019-05-161-14/+43
| | | | Add rules to support building Swift sources using Ninja.
generated by cgit v0.12 at 2025-01-13 11:18:14 (GMT)