Sure, here a more elaborate version of @niw's demo: https://github.com/patricknixon/spm-transitive
It demonstrates that:
SPM modules are visible transitively to all private code downstream.
SPM modules cannot be imported by a header that is included in any public umbrella header.
A framework will "re-export" SPM dependencies in its generated Objective-C compatibility header if needed, which leads to the issue in the original post. In addition, the demo shows that such a framework can be used from Objective-C code but not from Swift.
PaddyMcPat
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Post
Replies
Boosts
Views
Activity
Thank you for replying, Developer Tools Engineer . I work with @niw. The answer seems to imply that Xcode should never add -fmodule-map-file for SPM modules that are transitively linked, however for some dependencies it absolutely does work. For example, our app has a dependencies like:
App -> XcodeFrameworkA -> XcodeFrameworkB -> (static SPMLibrary) SPMModule
In Objective-C code in XcodeFrameworkA, this compiles and runs perfectly fine:
// Foo.m
// XcodeFrameworkA
@import SPMModule;
And the build logs show that the frontend flag is being added, e.g.
CompileC ... XCodeFrameworkA/Foo.m ... -fmodule-map-file=.../GeneratedModuleMaps/.../SPMModule.modulemap ...
My question is, what causes this kind of transitive dependency to work sometimes but not other times? Is this something we can rely on in the cases where it already "works"?