Closed vashworth closed 1 month ago
fyi @jmagman @stuartmorgan
@loic-sharma and I like this approach and are planning to move forward with it. If users want to use modulemaps with SwiftPM, we plan to point them to SwiftPM's documentation about it: https://github.com/apple/swift-package-manager/blob/main/Documentation/Usage.md#creating-c-language-targets
If users want to use modulemaps with SwiftPM, we plan to point them to SwiftPM's documentation about it: https://github.com/apple/swift-package-manager/blob/main/Documentation/Usage.md#creating-c-language-targets
I created an experiment that allows for custom module maps with SwiftPM: https://github.com/flutter/packages/compare/main...loic-sharma:flutter-packages:spm_camera_separate_public_file_symlinks
This works by creating separate header directories for CocoaPods (/cocoapods_headers
) and Swift Package Manager (/include
). To minimize duplication, the CocoaPods header files are symlinks back to the header files in the Swift Package Manager header directory. I verified this works on Xcode 14.2+. Some drawbacks to this approach:
#import "..."
paths. This is incompatible with this experiment as the relative path to the header files changes depending on whether you're using CocoaPods or Swift Package Manager. Instead, the Pigeon implementation file should use non-relative imports like #import <my_plugin/MyHeader.h>
. Today, this requires manually editing the code generated by Pigeon.flutter/packages
repo, we'd likely want tooling/tests to verify CocoaPods/SwiftPM header files are in sync.Due to these drawbacks we prefer to avoid module maps in SwiftPM if possible.
In the tests:
@import camera_avfoundation;
@import camera_avfoundation_test;
If we were only in SwiftPM world, could we normally #import
the test headers directly? Or was there some problem with the hmap?
In the tests:
@import camera_avfoundation; @import camera_avfoundation_test;
If we were only in SwiftPM world, could we normally
#import
the test headers directly? Or was there some problem with the hmap?
We could do imports directly.
That actually makes me realize, we can simplify this even further. Since all the headers are public and we're not using a custom umbrella header and modulemap, we don't need to do a separate target or import separate headers. All the headers should be available via the @import camera_avfoundation;
since it's no longer limited by the umbrella header. I updated the Proposal and prototype
Most of the work in this issue is completed. The exception is this step, which is blocked until we remove support for CocoaPods:
Re-adding SwiftPM
.modulemap
sOnce the ecosystem has migrated to SwiftPM, we will remove support for CocoaPods. At this point, we should consider re-adding
module.modulemap
s to the plugins' SwiftPM integration. This step might not be necessary as we plan to rewrite plugins in Swift.
I'll track this final step separately in the parent issue
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v
and a minimal reproduction of the issue.
Use case
To support both CocoaPods and Swift Package Manager, dynamic and static linking, two different modulemaps are needed.
CocoaPods modulemap
CocoaPods seems to require the modulemap be a
framework
module and doesn't use relative paths.For example,
SwiftPM modulemap
SwiftPM requires the modulemap to be named
module.modulemap
and be located within theinclude
directory. It also doesn't seem to work if defined as aframework
module and uses relative paths.For example,
The problem
The problem is that when you have two modulemaps (most likely also because one is named
module.modulemap
, which is the implicit modulemap file), this can cause issues:Proposal
It's been pretty difficult to figure out a way to support both CocoaPods and SwiftPM modulemaps. As a result, we're leaning towards eliminating modulemaps in SwiftPM.
Instead of using a modulemap and umbrella header for the SwiftPM integration of plugins, we simply allow all public headers to be available via
@import plugin_name_ios
.The headers are already public and could be imported individually (like
#import <plugin_name_ios/PublicHeader_Test.h>
), so making them available through the module isn't much worse.Modulemap and umbrella header should be excluded from SwiftPM target:
Unit tests can also be kept compatible with both CocoaPods and SwiftPM with something like:
Prototype
https://github.com/flutter/packages/compare/main...vashworth:packages:camera_avfoundation_remove_swiftpm_modulemap
Re-adding SwiftPM
.modulemap
sOnce the ecosystem has migrated to SwiftPM, we will remove support for CocoaPods. At this point, we should consider re-adding
module.modulemap
s to the plugins' SwiftPM integration. This step might not be necessary as we plan to rewrite plugins in Swift.