Add flutter build macos-framework command#105242
Add flutter build macos-framework command#105242fluttergithubbot merged 3 commits intoflutter:masterfrom
Conversation
jmagman
added
tool
flutter-dashboard
bot
added
the
c: contributor-productivity
| Future<Set<DevelopmentArtifact>> get requiredArtifacts async => const <DevelopmentArtifact>{ | ||
| DevelopmentArtifact.macOS, | ||
| }; |
There was a problem hiding this comment.
nit:
| Future<Set<DevelopmentArtifact>> get requiredArtifacts async => const <DevelopmentArtifact>{ | |
| DevelopmentArtifact.macOS, | |
| }; | |
| Future<Set<DevelopmentArtifact>> get requiredArtifacts async => const <DevelopmentArtifact>{ | |
| DevelopmentArtifact.macOS, | |
| }; |
There was a problem hiding this comment.
dart-fmt did this 🙁 let me fix by hand.
| /// contains the Flutter engine and framework code as well as plugins. It can | ||
| /// be integrated into plain Xcode projects without using or other package | ||
| /// managers. | ||
| class BuildMacOSFrameworkCommand extends BuildFrameworkCommand { |
There was a problem hiding this comment.
I wanted to share more between this and BuildIOSFrameworkCommand but almost every line is subtly different.
For example, the iOS assemble target only creates App.framework, but the macOS one creates App.framework and copies FlutterMacOS.framework, so a separate copy isn't needed. iOS publishes Flutter.xcframework, but macOS publishes FlutterMacOS.framework, which means the xcframework needs to be created. iOS has extra logic for building simulator frameworks, etc.
| } | ||
|
|
||
| final Status status = | ||
| globals.logger.startProgress(' └─Moving to ${globals.fs.path.relative(modeDirectory.path)}'); |
There was a problem hiding this comment.
This doesn't look like it matches what the following try block is doing?
There was a problem hiding this comment.
You're right, I'll change to a printStatus since I still want to convey the path.
| modeDirectory.deleteSync(recursive: true); | ||
| } | ||
|
|
||
| if (boolArg('cocoapods') ?? false) { |
There was a problem hiding this comment.
Should we make these boolArg(...)!? (I believe) the only way this would error out is if a later refactor to the arg parsing results in this command no longer having a cocoapods flag and this code wasn't updated, which would be a tool bug that we'd want to know about.
There was a problem hiding this comment.
@Jasguerrero I keep running into this pattern. Can we make boolArg return a nonnull bool to simplify the code, and have it throw an exception (not toolExit since it's a developer error) if the flag doesn't exist?
There was a problem hiding this comment.
that's a good idea
3 participants
Implement
flutter build macos-frameworkto support basic add-to-app for macOS. This can be run from a normal macOS Flutter app, it does not implement the module template.I don't like the stray
Building App.framework for arm64..logging but it's not coming from this PR, we can address that later.See also refactoring work in #105194
Fixes #104866
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.