Generate the compatibility header for libraries on all platforms #8695
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Enable generating the compatibility header for library targets on all platforms by lifting the restriction on Darwin. As part of the work to formalize `@cdecl` we've been adding content to the compatibility header that is usable by C compilers without the need for Objective-C or modules. Lifting this restriction will allow Linux and Windows users to generate and import the compatibility header in their packages.
xymus
requested review from
jakepetroules,
dschaefer2,
shawnhyam,
bripeticca,
plemarquand,
owenv,
bkhouri,
cmcgee1024 and
daveyc123
as code owners
|
@swift-ci Please test |
|
Woohoo! |
Now that compatibility header tests run on Windows we need to update how we check for paths to support the platform properly.
|
@swift-ci Please test |
|
@swift-ci test windows |
|
Took a quick look at Swift Build and I think we don't need any changes there; I see in my Android builds that the -Swift.h file is already being generated. |
jakepetroules
approved these changes
May 20, 2025
DougGregor
reviewed
May 20, 2025
|
@swift-ci Please test windows |
3 similar comments
|
@swift-ci Please test windows |
|
@swift-ci Please test windows |
|
@swift-ci Please test windows |
|
I found two related issues. #7319 should be fixed by this PR as they were only asking for the compatibility header to be generated on non-Darwin platforms. However there are still hurdles to import the compatibility header from a C/C++ source file and actually use it. I'm aware of two restrictions, both mentioned in #7257: the module map for the compatibility header is printed with |
dschaefer2
pushed a commit
that referenced
this pull request
Jul 3, 2025
…t libraries (#8736) Address two issues preventing a C source file to import the generated compatibility header: 1. Don't mark the module map generated for the compatibility header as `requires objc`. This triggers an error when importing it from a C source file. The compatibility header is already printed in a way where the Objective-C code is protected behind a language check. C clients can safely import it even if they may not see any content. Plus we're adding C content to the compatibility header with the official support for `@cdecl` that is independent of Objective-C. 2. Emit the generated compatibility header and module map in a new `include` directory under the temporary build directory of each Swift library. This directory is then used as a header search path for the dependent clang targets. This replaces the previous strategy that relied only the generated module map to resolve imports. It was incompatible with C source files and non-modular textual includes. The use of a header search path preserves the support for module imports via the same module map and supports textual includes of the compatibility header. Fixes #7257. Follow up to #8695.
marcprux
pushed a commit
to swift-everywhere/swift-package-manager
that referenced
this pull request
Jul 7, 2025
…t libraries (swiftlang#8736) Address two issues preventing a C source file to import the generated compatibility header: 1. Don't mark the module map generated for the compatibility header as `requires objc`. This triggers an error when importing it from a C source file. The compatibility header is already printed in a way where the Objective-C code is protected behind a language check. C clients can safely import it even if they may not see any content. Plus we're adding C content to the compatibility header with the official support for `@cdecl` that is independent of Objective-C. 2. Emit the generated compatibility header and module map in a new `include` directory under the temporary build directory of each Swift library. This directory is then used as a header search path for the dependent clang targets. This replaces the previous strategy that relied only the generated module map to resolve imports. It was incompatible with C source files and non-modular textual includes. The use of a header search path preserves the support for module imports via the same module map and supports textual includes of the compatibility header. Fixes swiftlang#7257. Follow up to swiftlang#8695.
dschaefer2
pushed a commit
to dschaefer2/swift-package-manager
that referenced
this pull request
Jul 8, 2025
…t libraries (swiftlang#8736) Address two issues preventing a C source file to import the generated compatibility header: 1. Don't mark the module map generated for the compatibility header as `requires objc`. This triggers an error when importing it from a C source file. The compatibility header is already printed in a way where the Objective-C code is protected behind a language check. C clients can safely import it even if they may not see any content. Plus we're adding C content to the compatibility header with the official support for `@cdecl` that is independent of Objective-C. 2. Emit the generated compatibility header and module map in a new `include` directory under the temporary build directory of each Swift library. This directory is then used as a header search path for the dependent clang targets. This replaces the previous strategy that relied only the generated module map to resolve imports. It was incompatible with C source files and non-modular textual includes. The use of a header search path preserves the support for module imports via the same module map and supports textual includes of the compatibility header. Fixes swiftlang#7257. Follow up to swiftlang#8695.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Enable generating the compatibility header for library targets on all platforms by lifting the restriction to Darwin.
As part of the work to formalize
@cdeclwe've been adding content to the compatibility header that is usable by C compilers without the need for Objective-C or modules. Lifting this restriction will allow Linux and Windows users to generate and import the compatibility header to call@cdeclfunctions in their package.