summaryrefslogtreecommitdiffstats
path: root/Tests/RunCMake/Swift
Commit message (Collapse)AuthorAgeFilesLines
* 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-02-09 11:11:21 (GMT)