summaryrefslogtreecommitdiffstats
path: root/Tests/RunCMake/Swift
Commit message (Collapse)AuthorAgeFilesLines
* Swift/Ninja: Fix missing OFM in CMP0157 OLD behaviorEvan Wilde2023-12-192-3/+12
| | | | | | | | The CMP0157 old behavior omitted the output-file-map after the Swift build split because we stopped calling `EmitSwiftDependencyInfo` when we could not split the build because we didn't call `WriteObjectBuildStatement`. If we can't split the build, then we still need to include the OFM information to not break incremental builds.
* Swift/Ninja: Split compilation modelEvan Wilde2023-12-151-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Tests: Update Swift tests to use CMP0157 NEW behaviorEvan Wilde2023-11-173-0/+3
| | | | | Fixing failing tests caused by introduction of new policy + warning when the policy is not set.
* Swift: Add abstraction for compilation modeEvan Wilde2023-11-176-0/+45
| | | | | | | | | | | 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
* Tests: Simplify RunCMake.Swift conditions to enable use of SwiftBrad King2023-11-171-3/+3
|
* Tests/RunCMake: Update cmake_minimum_required versionsBrad King2023-02-113-5/+3
| | | | | | | | For policy-specific tests, use the version before the policy was introduced. Otherwise, use 3.5 where possible. Also, remove `cmake_minimum_required()` and `project()` calls from individual cases where they are handled by `CMakeLists.txt`.
* Add incremental Swift static lib build testEvan Wilde2023-01-215-0/+49
| | | | | | | | | Ensure that we're actually trying to rebuild libB when the public interface for libA changes. Without handling the swiftmodule dependency edge correctly, we would only get a linker error because libA didn't have the symbol that libB depended on. With the fix, we get a proper compiler error because ninja knows to rebuild the intermediate libB when the public interface of libA changes. This is more actionable.
* Ninja: Emit swiftmodule from executable with exportsEvan Wilde2023-01-191-1/+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.
* Ninja: Avoid re-linking a Swift executable on every buildEvan Wilde2022-11-174-0/+13
| | | | | | Swift doesn't emit swiftmodules for executables, so we shouldn't put it in dependency graph. Ninja sees the "missing" dependency and always tries to rebuild/re-link the target.
* Swift: Ignore WIN32_EXECUTABLE property outside of Windowshotwatermorning2021-10-282-5/+12
| | | | Issue: #19877
* Swift: support Ninja Multi-ConfigSaleem Abdulrasool2020-03-093-0/+9
| | | | | Enable support for multi-configuration builds using Ninja when building Swift.
* Swift: disallow multiple `CMAKE_OSX_ARCHITECTURES` with SwiftSaleem Abdulrasool2020-01-284-0/+13
| | | | | This disallows the use of multiple values in `CMAKE_OSX_ARCHITECTURES` with Swift which does not support FAT compilation.
* Swift: disallow WIN32_EXECUTABLE propertiesSaleem Abdulrasool2019-06-035-1/+12
| | | | | | | | | | | Currently, the compiler does not synthesize the correct entry point for the application and passing the subsystem flag does not work the same way with the Swift linker language. Add a check to prevent the application of `WIN32_EXECUTABLE` to Swift executables until they can be properly supported. This will prevent the need for a future policy change. Closes: #19325
* Tests: add a check for the Swift compilerSaleem Abdulrasool2019-05-171-0/+4
| | | | This ensures that the tests only run when the Swift compiler is present.
* Swift: Remove positive Swift language testsGregor Jasny2015-09-063-4/+0
| | | | | | | | | | | | | It's relatively complex to determine in advance if a Xcode, SDK, and Deployment Target configuration is capable of running Swift. For example the following combinations do not work: * deployment target < OS X 10.9 * Xcode 6.2 and macosx10.9 SDK * Xcode 7 Beta 6 and macosx10.10 SDK Until we found out how to query Xcode for Swift support in a reliable way, the RunCMake.Swift test cases will be restricted to negative ones.
* Add rudimentary support for the Apple Swift language with XcodeBrad King2015-07-0610-0/+30
Allow the `Swift` language to be enabled with the Xcode generator for Xcode >= 6.1. Reject it on other generators and with older Xcode versions. Since Apple is the only vendor implementing the language right now, the compiler id can be just `Apple`.
generated by cgit v0.12 at 2025-09-04 00:11:40 (GMT)