* Adds markdown formatting to better highlight the important bits.
* Removes the bit about patch files not being valid because they are
copied from the GitHub UI (we use LUCI now).
* Add a shortcut for Mac to apply the patch from your pasteboard.
Updates the linting script to ban the use of `VERSION_CODES`.
We currently have a mish-mash of using the integers, using `VERSION_CODES`, and even how we import the version codes. This makes it more confusing when doing things like #51070 - I think it is clearer to see `22` than `LOLLIPOP_MR1`.
I'd like to get LGTM (or at least no opinion) from all the requested reviewers here.
The Dart -> Flutter Engine autoroller seems to be failing atm due to
fuchsia build errors.
The Dart SDK CL in [0] is depending on a fuchsia gn sdk import. The
import path defaults to `//third_party/fuchsia/gn-sdk` in the Dart build
rules.
Though flutter seemingly has it in `//flutter/tools/fuchsia/gn-sdk`
(which was added to DEPS in c274921fa6034e5e133129967c0789ab8c7fc827)
=> This is an attempt to override the default & fix autoroller
[0] https://dart-review.googlesource.com/c/sdk/+/355283/14
Files under the build_overrides directory in the buildroot are typically hardcoded imports in third-party dependencies used for project-specific configuration. For example, ANGLE hardcodes an import of `//build_overrides/angle.gni` so that consumers of ANGLE can configure the build to their needs.
This adds a copy all existing src/build_overrides files at the equivalent `src/flutter/build_overrides` path in the engine. A followup patch will replace each existing file under `src/build_overrides` in the buildroot with a shim that just imports the files landed in this patch. This allows third-party dependencies to continue hardcoding the `//build_overrides/foo.gni` path, but provides a seamless path forward when we drop the buildroot.
Issue: https://github.com/flutter/flutter/issues/144790
Part of: https://github.com/flutter/flutter/issues/67373
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Allow users to update dependencies. Examples:
* `et fetch` Fetch dependencies
In the future, `et build` will update dependencies if it detects that they have changed.
Also:
* Updates the status in the README
* Adds instructions on how to run tests
* Fixes `et run`'s description
* Makes the `--verbose` flag global
This PR adds githooks for `post-checkout`, `post-merge`, `pre-rebase`
that remind to run `gclient sync -D`. This is probably going to print
the reminder too much. The `pre-rebase` hook runs before a `git pull
--rebase` that is actually going to update something, but the other
hooks may be needed to cover other workflows. The printed message will
also include the hook that it comes from, so we can remove the message
from hooks where it doesn't make sense.
<img width="670" alt="Screenshot 2024-03-04 at 18 36 15"
src="https://github.com/flutter/engine/assets/6343103/4d3e4661-035d-4ed6-8ed6-2a05b372bf65">
This was introduced in #51070 - my grepping for `LOLLIPOP` was too aggressive, and apparently the linter didn't catch this. I think it's just a bug in the linter.
Fixes b/327717572, because Google internal tests caught this.
Currently, these scripts run on each invocation of `gn`, and can take
many seconds to run.
This PR shifts them to run as `gclient` hooks instead, so that `gn` will
be faster.
Needs https://github.com/flutter/buildroot/pull/825.
Basically, I take blank images of red/blue/green squares, like this:
... and use Image Magick to annotate it with the current git hash:
```sh
$ drt ./testing/skia_gold_client/tool/generate.dart
Writing annotation "8069cb4ca1" on images in testing/skia_gold_client/tool/source_images and saving them in testing/skia_gold_client/tool/e2e_fixtures.
Writing to testing/skia_gold_client/tool/e2e_fixtures/solid_red_square.png
Writing to testing/skia_gold_client/tool/e2e_fixtures/solid_green_square.png
Writing to testing/skia_gold_client/tool/e2e_fixtures/solid_blue_square.png
Done: wrote 3 image.
```
... then, I upload the digests very similar to how we do it in `scenario_app`.
---
The idea here is to have a way for me to know if Skia gold is working the way I/we expect, independent of a more complicated test suite with various race-y or flake-y conditions. We could also augment it with tests of "dimensions" properties.
The `run` command builds both the host and target engines and then invokes `flutter run` so that it runs the app using the custom engine builds.
It is expected that 'et run' be used inside the directory of a flutter application.
Command line flags passed after `--` will be forwarded to `flutter run`.
Some examples:
- `et run` Build the debug variant and runs the app in that mode.
- `et run -- --profile` Build the profile variant and runs the app in that mode.
- `et run -- --release` Build the release variant and runs the app in that mode.
Also:
- Start a local_engine.json builder definition (it is missing a lot)
- Tweak the test fixture.
- Add a new Matcher to litetest.
- Tweaked the build config linter to only care about duplicate build names within the same builder.
This reverts commit 98485b3f82fec45a6a0ac932c3c20285a9a14e02.
Reverted in https://github.com/flutter/engine/pull/51056 because it
caused failures in the framework. No changes, but framework test has
been updated to use an actual robolectric implementation to avoid those
failures.
This should not land until
https://github.com/flutter/flutter/pull/144348 has landed in the
framework.
@gaaclarke @johnmccutchan fyi
Fuchsia team is working on getting rid of non-versioned libraries and sysroot (see b/40935282), but flutter is using a fairly old version of in-house gn-sdk. It's hard to maintain it anymore.
So this change removes the in-house gn-sdk and replaces it with the gn-sdk from chromium.
This is a prerequisite to select the idk / sdk lib version according to the api-level.
This change contains three parts:
1) Replacing gn-sdk/ with gn-sdk/src/ since the chromium needs a README.chromium in gn-sdk/ folder.
2) Making the existing build rules work with the newer gn-sdk.
3) Drive-by replacing "gtest_runner.shard.cml" with "sys/testing/gtest_runner.shard.cml", it's in fuchsia sdk already.
Bug: [b/40935282](https://issues.chromium.org/issues/40935282?pli=1&authuser=0)
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
For https://github.com/flutter/flutter/issues/67373
Currently the files in the secondary buildroot for protobuf are checked
out from their own git repo. Flutter owns a mirror of that repo. To move
protobuf to `//flutter/third_party`, we can land a change in that repo,
and then revert it after we're done with the buildmoot. Alternately, in
this PR, I've just copied the files into the flutter/engine repo under
the secondary buildroot and made the changes.
* Adds a 'build' command to `et`.
* Renamed `query builds` to `query builders` because that seemed to be
more precise(?)
Some extra requests during review:
1. I've left some questions I'd like answers to at the top of
`build_command.dart` I suspect @zanderso and @loic-sharma can give me
(some?) answers.
2. I suspect I'm holding the FakeProcessManager wrong or there is a
better way to write the tests in `build_command_test.dart`. Pointers to
good examples are appreciated.
Towards https://github.com/flutter/flutter/issues/132807.
This is needed so the engine tool can map the names of CI builders
listed in `.ci.yaml` to the names of the configurations in the build
config json files in `ci/builders`.
This PR changes the format check on CI to use the command added in
https://github.com/flutter/engine/pull/50747.
Additionally, while making this change, I noticed that the CI check was
not checking the formatting of all files, and that as a result, files
were present in the repo with incorrect formatting. I have fixed the
formatting and fixed the check to always check all files.
pub get --offline may fetch packages that are in the local package cache but were previously downloaded from a hosted source. The script needs to check for packages that came from either the old or new locations of the Dart hosted package repository.
