summaryrefslogtreecommitdiffstats
path: root/Tests/SwiftOnly
Commit message (Collapse)AuthorAgeFilesLines
* Ninja: Emit swiftmodule from executable with exportsEvan Wilde2023-01-194-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Xcode: Implement Swift include directoriesBrad King2022-11-025-0/+8
| | | | | | | Populate Xcode's `SWIFT_INCLUDE_PATHS` build setting with the target-wide include directories. Issue: #24116
* Xcode: Pass compile definitions to SwiftDavid Geldreich2022-07-072-0/+7
| | | | | | | | | | correct Xcode generator Swift definitions original code was defining GCC_PREPROCESSOR_DEFINITIONS which is valid only for C languages add definitions to SWIFT_ACTIVE_COMPILATION_CONDITIONS when Swift language is used in the target add test in SwiftOnly for old Xcode (<8.0), append defines to cflags so it ends up in OTHER_SWIFT_FLAGS Fixes: #23637
* Swift: Update test case to try CMP0126 NEW behaviorBrad King2021-07-211-0/+3
| | | | | | | | Extend the `SwiftOnly` test to cover the fix in commit 3ddd7f3576 (enable_language: Fix test for working compiler with CMP0126 NEW behavior, 2021-07-15), as that commit did for the `CSharpOnly` test. Fixes: #22451
* Swift: Fix regression in linking to interface librariesBrad King2020-07-171-0/+1
| | | | | | | | | | Since commit 2026915f8f (Swift: Propagate Swift_MODULE_DIRECTORY as include directory, 2020-02-03, v3.18.0-rc1~547^2) we internally call `GetAllConfigCompileLanguages` on all directly linked targets without checking if they are interface libraries that don't compile at all. That violates an internal assumption and assertion. Fixes: #20977
* Swift: Propagate Swift_MODULE_DIRECTORY as include directorySaleem Abdulrasool2020-03-124-0/+29
| | | | | | | | | Teach include directory computation for Swift to implicitly propagate the `Swift_MODULE_DIRECTORY` of all linked targets as include directories. This is required to ensure that the swiftmodule of a linked target is accessible to the compiler of the current target. Fixes: #19272
* Swift: Restore support for enabling with INTERFACE librariesBrad King2019-07-291-0/+3
| | | | | | | | | | | The check added in commit b06f4c8a74 (Swift: disallow WIN32_EXECUTABLE properties, 2019-05-31, v3.15.0-rc1~9^2) makes sense only for executables because the `WIN32_EXECUTABLE` property is defined only for them. Running the check on other target types, particularly those that do not link such as INTERFACE libraries, violates internal assumptions. In particular, `GetLinkerLanguage` should not be called on such targets. Fixes: #19528
* Xcode: Update default Swift language version for Xcode 10.2Brad King2019-02-041-1/+3
| | | | | | Xcode 10.2 no longer supports Swift language versions before 4.0. Fixes: #18871
* Xcode: Add option to set Swift language versionBrad King2016-09-261-0/+4
| | | | | | | | | | Create a new CMAKE_Swift_LANGUAGE_VERSION variable to specify the SWIFT_VERSION attribute in a generated Xcode project. Ideally this would be a `<LANG>_STANDARD` property but since Swift support is very minimal we should reserve that property for more complete treatment later. Issue: #16326
* Swift: Use dump instead of printlnGregor Jasny2015-09-011-1/+1
| | | | | With Swift 2.0 in Xcode7 the println function was renamed into print. Use dump function instead which adds newlines like println.
* Add rudimentary support for the Apple Swift language with XcodeBrad King2015-07-062-0/+5
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-01-21 02:04:54 (GMT)