[flutter_plugin_tool] Add support for building UWP plugins #4047
Conversation
|
Sorry this turned into a yak-shave; once I was changing that test utility method it was very hard to stop... |
|
Hold off on reviewing; I re-implemented most of the yak as a prequel PR. |
|
Now with 100% less yak. |
| // needs to be created on the fly with 'flutter create .' | ||
| Directory? temporaryPlatformDirectory; | ||
| if (flutterBuildType == 'winuwp') { | ||
| final Directory uwpFolder = example.childDirectory('winuwp'); |
There was a problem hiding this comment.
pedantic nit: consider uwpDirectory for consistent naming with the APIs, unless folder is used consistently throughout the tool already.
There was a problem hiding this comment.
Fixed (that's my macOS showing).
| if (!uwpFolder.existsSync()) { | ||
| print('Creating temporary winuwp folder'); | ||
| final int exitCode = await processRunner.runAndStream( | ||
| flutterCommand, <String>['create', '--platforms=winuwp', '.'], |
There was a problem hiding this comment.
Is this winuwp the same as the platformVariantWinUwp or kPlatformWinUwp const in core.dart? If so consider using a string interpolation here both to indicate the connection, and because it'll break this code if we ever removed that const.
There was a problem hiding this comment.
Is this
winuwpthe same as theplatformVariantWinUwporkPlatformWinUwpconst incore.dart?
Hm. I guess it's probably the same as kPlatformWinUwp now that you mention it ("UWP is a platform for the purposes of flutter commands like build and run"); presumably the fact that build and create are using the same string in flutter isn't an accident.
The "platform" situation is kind of a disaster. I think the thing to do is to explore doing a follow-up PR that makes a tool-wide platform class that's based on the _PlatformDetails I had to define here, because it's a more general problem (as indicated by the constant names we have globally). That can have accessors for each different usage; mostly that will be the same thing in each case, but not always, and we can pass around that object internally everywhere instead of strings (and only convert to strings at the last minute when interfacing with things outside the tool).
| FileSystemEntity entity, { | ||
| PlatformSupport? requiredMode, | ||
| String? variant, | ||
| }) { | ||
| assert(platform == kPlatformIos || |
There was a problem hiding this comment.
Should this be updated to include kPlatformWinUwp or is that always passed as kPlatformWindows with the uwp variant?
There was a problem hiding this comment.
The latter; from the standpoint of a plugin, UWP isn't a platform.
(But see my other comment; I think I could avoid this kind of confusion with a generic platform class.)
There was a problem hiding this comment.
Agreed; the backward compatibility makes this a bit of a pain. As you say, modelling this with classes might result in better readability than with logic in various bits of the tool. Agree that approach is worth exploring.
| // The UWP template is not yet stable, so the UWP directory | ||
| // needs to be created on the fly with 'flutter create .' | ||
| Directory? temporaryPlatformDirectory; | ||
| if (flutterBuildType == 'winuwp') { |
There was a problem hiding this comment.
It looks like these are currently literals for all the platforms; consider extracting them to build type consts.
| @@ -656,6 +656,40 @@ void main() { | |||
| ])); | |||
| }); | |||
|
|
|||
| test('driving UWP is a no-op', () async { | |||
There was a problem hiding this comment.
Might be useful to add a TODO here and elsewhere with a link to a bug.
|
The red is a flaky test that I have a PR out for review to disable, so I'm going to land without wasting the resources of re-running it until it's green. |
) This allows building UWP plugin examples with `build-examples --winuwp`. As with previous pre-stable-template desktop support, this avoids the issue of unstable app templates by running `flutter create` on the fly before trying to build, so a template that will bitrot doesn't need to be checked in. Also adds no-op "support" for `drive-examples --winuwp`, with warnings about it not doing anything. This is to handle the fact that the LUCI recipe is shared between Win32 and UWP, and didn't conditionalize `drive`. Rather than change that, then change it back later, this just adds the no-op support now (since changing the tooling is much easier than changing LUCI recipes currently). This required some supporting tool changes: - Adds the ability to check for the new platform variants in a pubspec - Adds the ability to write test pubspecs that include variants, for testing Part of flutter/flutter#82817
) This allows building UWP plugin examples with `build-examples --winuwp`. As with previous pre-stable-template desktop support, this avoids the issue of unstable app templates by running `flutter create` on the fly before trying to build, so a template that will bitrot doesn't need to be checked in. Also adds no-op "support" for `drive-examples --winuwp`, with warnings about it not doing anything. This is to handle the fact that the LUCI recipe is shared between Win32 and UWP, and didn't conditionalize `drive`. Rather than change that, then change it back later, this just adds the no-op support now (since changing the tooling is much easier than changing LUCI recipes currently). This required some supporting tool changes: - Adds the ability to check for the new platform variants in a pubspec - Adds the ability to write test pubspecs that include variants, for testing Part of flutter/flutter#82817
This allows building UWP plugin examples with
build-examples --winuwp. As with previous pre-stable-template desktop support, this avoids the issue of unstable app templates by runningflutter createon the fly before trying to build, so a template that will bitrot doesn't need to be checked in.Also adds no-op "support" for
drive-examples --winuwp, with warnings about it not doing anything. This is to handle the fact that the LUCI recipe is shared between Win32 and UWP, and didn't conditionalizedrive. Rather than change that, then change it back later, this just adds the no-op support now (since changing the tooling is much easier than changing LUCI recipes currently).This required some supporting tool changes:
Part of flutter/flutter#82817
Pre-launch Checklist
dart format.)[shared_preferences]///).