Jonah Williams f1472e1fc4
[flutter_tools] only lock if an upgrade/download will be performed (linux/macos) and output building messages to stderr (#65422)
Currently an invocation of flutter/dart will always attempt to acquire a lock. This can pose problems for tools that attempt to run multiple dart/flutter instances.

Instead update the lock logic (on Linux/macOS) so that we only attempt to acquire it if an update/snapshot needs to be performed. To avoid repeatedly performing downloads/snapshots if multiple flutter/dart invocations are fired off concurrently when an update needs to be performed, do a second check of the download/snapshot condition after the lock is released.

Additionally, moves all of the building/debug output to stderr on both the bash and batch scripts. This allows machine mode consumption of the tool to ignore needing to parse/handle the rebuild messages.
2020-09-22 17:44:08 -07:00
..
2020-09-02 18:35:05 -07:00

Dart SDK dependency

The bin/internal/engine.version file controls which version of the Flutter engine to use. The file contains the commit hash of a commit in the https://github.com/flutter/engine repository. That hash must have successfully been compiled on https://build.chromium.org/p/client.flutter/ and had its artifacts (the binaries that run on Android and iOS, the compiler, etc) successfully uploaded to Google Cloud Storage.

The /bin/internal/engine.merge_method file controls how we merge a pull request created by the engine auto-roller. If it's squash, there's only one commit for a pull request no matter how many engine commits there are inside that pull request. If it's rebase, the number of commits in the framework is equal to the number of engine commits in the pull request. The latter method makes it easier to detect regressions but costs more test resources.