Treats 'pluginClass: none' as equivalent to having no 'pluginClass'
entry on the desktop platforms, to satisy stable channel plugin
validation of Dart-only desktop plugin implementations. See
issue for full details.
Part of https://github.com/flutter/flutter/issues/57497
To simplify development of the in-progress GTK embedding, which will
replace the GLFW embedding on Linux, add the GTK artifacts to the unpack
list. This means that until the transition, both the GLFW and GTK
artifacts will be unpacked.
Part of #54860
The -S/-B format of specifying source and build directories wasn't added
until 3.13. For 3.10 compatibility, use the older form of having the
working directory as the build directory, and the last argument as the
source directory.
Fixes#57409
Throw a toolExit if the windows plugin logic runs on an invalid windows project. Update the supported project check to validate the existence of a Runner.sln file
Updates the Linux templates to use CMake+ninja, rather than Make, and updates the tooling to generate CMake support files rather than Make support files, and to drive the build using cmake and ninja.
Also updates doctor to check for cmake and ninja in place of make.
Note: While we could use CMake+Make rather than CMake+ninja, in testing ninja handled the tool_backend.sh call much better, calling it only once rather than once per dependent target. While it does add another dependency that people are less likely to already have, it's widely available in package managers, as well as being available as a direct download. Longer term, we could potentially switch from ninja to Make if it's an issue.
Fixes#52751
The default for build for flutter build ios should be release to match the other build commands. This is correctly handled in the command, but the documentation is incorrect. Update the documentation and the default to reflect the more common case of building for a physical device.
`assert(app is IOSApp)` fails if `app` is null, and `app` is an
optional argument. `app` is passed to `_IOSSimulatorLogReader`, which
already handles it being null.
Remove caching of FlutterView. Perhaps the FlutterView RPC might return an empty list if the VM is not quite up yet? We had some old logic to poll the flutter views RPC for up to 200ms. That doesn't seem like a great approach, so instead we could forgo it entirely and trust that either the views come up before the developer tries to interact, or we crash.
