New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SR-14575] Frameworks built from Swift packages lack a Headers folder #4430
Comments
Comment by Jonathan Gilbert (JIRA) Note: I confirm this is fixed in Xcode 12.5 / Swift 5.4 toolchain. |
Comment by Jonathan Gilbert (JIRA)
|
Comment by Jonathan Gilbert (JIRA) Nevermind, it's actually NOT fixed in Swift 5.4. |
Hi, did this bug fixed now? Any milestones? |
The current behavior is intentional here. Frameworks produced for packages in Xcode are not meant for further consumption at build time, they are merely meant for being included for use at runtime by other built products, like apps. This is because there is an impedance mismatch between frameworks and package products because the former always contains a single module and the later can contain more than one. |
Environment
Xcode 12.5/Swift 5.4
Additional Detail from JIRA
md5: d1fef8db1659268b03d58ce70e8c5b8c
blocks:
@objc
in Swift code causes Objective-C module failure with transitive depdencyIssue Description:
When a Swift package Foo declares a dynamic library product for a Swift target Foo that declares some @objc protocols and classes, building that package should result in a framework Foo.framework that has a headers folder Foo.framework/Headers/ containing auto-synthesized Foo.h that includes Foo-Swift.h. That way, Xcode projects with Obj. C code can simply link to Foo.framework and use any @objc code declared therein.
However the current version of SPM fails to add this Headers folder, resulting in any @objc APIs in Foo being invisible to Obj. C code in any modules that link to Foo.framework.
This seems like it should be easy to rectify...
The text was updated successfully, but these errors were encountered: