57fcee28c7
Windows plugins are designed to share implementations between Win32 and UWP, but not all plugins will support both. This adds a new 'supportedVariants' key to Windows plugins that allows specifying 'win32' and/or 'uwp' (and potentially others in the future in case that becomes necessary). Plugins without any supported variants will be assumed to be Win32 for backward compatibility. This will allow compiling Windows projects that use Win32-only Windows plugins (which is currently all of them) in UWP mode. The plugins will of course throw missing implementation exceptions at runtime, but tehy won't prevent being able to build as they currently do. Fixes https://github.com/flutter/flutter/issues/82815 |
||
|---|---|---|
| .. | ||
| bin | ||
| doc | ||
| gradle | ||
| ide_templates/intellij | ||
| lib | ||
| static | ||
| templates | ||
| test | ||
| tool | ||
| analysis_options.yaml | ||
| dart_test.yaml | ||
| pubspec.yaml | ||
| README.md | ||
Flutter Tools
This section of the Flutter repository contains the command line developer tools for building Flutter applications.
Working on Flutter Tools
Be sure to follow the instructions on CONTRIBUTING.md to set up your development environment. Further, familiarize yourself with the style guide, which we follow.
Setting up
First, ensure that the Dart SDK and other necessary artifacts are available by invoking the Flutter Tools wrapper script. In this directory run:
$ flutter --version
Running the Tool
To run Flutter Tools from source, in this directory run:
$ dart bin/flutter_tools.dart
followed by command-line arguments, as usual.
Running the analyzer
To run the analyzer on Flutter Tools, in this directory run:
$ flutter analyze
Writing tests
As with other parts of the Flutter repository, all changes in behavior must be
tested.
Tests live under the test/ subdirectory.
- Hermetic unit tests of tool internals go under
test/general.shard. - Tests of tool commands go under
test/commands.shard. Hermetic tests go under itshermetic/subdirectory. Non-hermetic tests go under itspermeablesub-directory. - Integration tests (e.g. tests that run the tool in a subprocess) go under
test/integration.shard.
In general, the tests for the code in a file called file.dart should go in a
file called file_test.dart in the subdirectory that matches the behavior of
the test.
Using local engine builds in integration tests
The integration tests can be configured to use a specific local engine
variant by setting the FLUTTER_LOCAL_ENGINE environment variable to the
name of the local engine (e.g. "android_debug_unopt"). If the local engine build
requires a source path, this can be provided by setting the FLUTTER_LOCAL_ENGINE_SRC_PATH
environment variable. This second variable is not necessary if the flutter and
engine checkouts are in adjacent directories.
export FLUTTER_LOCAL_ENGINE=android_debug_unopt
flutter test test/integration.shard/some_test_case
Running the tests
To run the tests in the test/ directory:
$ flutter test
The tests in test/integration.shard are slower to run than the tests in
test/general.shard. Depending on your development computer, you might
want to increase timeouts and limit concurrency.
The integration tests also require the FLUTTER_ROOT environment variable
to be set.
The full invocation to run everything might therefore look something like:
$ FLUTTER_ROOT=~/path/to/flutter-sdk
$ flutter test --timeout 2x --concurrency 1
This will take about an hour to complete.
To run only the tests in test/general.shard (which takes about a minute),
in this directory run:
$ flutter test test/general.shard
To run the tests in a specific file, run:
$ flutter test test/general.shard/utils_test.dart
Forcing snapshot regeneration
To force the Flutter Tools snapshot to be regenerated, delete the following files:
$ rm ../../bin/cache/flutter_tools.stamp ../../bin/cache/flutter_tools.snapshot