| commit | bdcc697d8afe46e47ed06e7460d66bd9d6be1a29 | [log] [tgz] |
|---|---|---|
| author | pq <pquitslund@google.com> | Mon Jan 08 19:31:21 2024 +0000 |
| committer | dart-internal-monorepo <dart-internal-monorepo@dart-ci-internal.iam.gserviceaccount.com> | Mon Jan 08 11:33:21 2024 -0800 |
| tree | d80054587ee500e2ebf291b3ed7a3d0f6bd9f518 | |
| parent | b55933c5349908048bd0019186c1ea68b2251c21 [diff] |
Reland "options map support scaffolding in driver" (with a re-introduced optional `analysisOptions` param) This is a reland of commit 717ce7a69cfd190887181dfbe07d4bdeeec104d6 with a slight modification to `AnalysisDriver` to allow Google3 clients to pass an analysisOptions object in. The logic to accommodate this is only temporary and will go away as soon as I can update clients to use an options map instead. Original change's description: > options map support scaffolding in driver > > Konstantin and I chatted a bit about this so at least some of it shouldn't be too surprising to him but please do feel free to grab me to chat. > > That said a few pointers would be handy. Notably, this change: > > * introduces a new `SharedOptionsOptionsMap` for use in SDK drivers (and preserve current semantics) > * this is currently public but will be private once driver is more evolved to accommodate multiple options files > * removes the shared `_analysisOptions` from the analysis driver with a baby step to using the one shared in SharedOptionsOptionsMap > * removes context_builder and collection v2 experiments (and tests) > * I'll harvest some more functionality from these in future changes but for now they're distracting and hard to maintain > > This work is all to setup moving analysis options awareness into file state objects which will allow us to remove `sdkVersionConstraint` info from options (finally) and a host of other good stuff (see https://github.com/dart-lang/sdk/issues/54124). > > > > Change-Id: Ic4278184016d1018b4b5b1c6ac5ba9e2546927a5 > Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/344860 > Reviewed-by: Brian Wilkerson <brianwilkerson@google.com> > Reviewed-by: Konstantin Shcheglov <scheglov@google.com> > Commit-Queue: Phil Quitslund <pquitslund@google.com> Change-Id: Iac9c4eb1aa448f2ca44e32dfb6cdf7cf765b6027 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/344944 Reviewed-by: Konstantin Shcheglov <scheglov@google.com> Reviewed-by: Brian Wilkerson <brianwilkerson@google.com> Commit-Queue: Phil Quitslund <pquitslund@google.com> https://dart.googlesource.com/sdk/+/3224637bb1d9ab2719bdb7140fd5e60432131acf
Monorepo is:
With depot_tools installed and on your path, create a directory for your monorepo checkout and run these commands to create a gclient solution in that directory:
mkdir monorepo cd monorepo gclient config --unmanaged https://dart.googlesource.com/monorepo gclient sync -D
This gives you a checkout in the monorepo directory that contains:
monorepo/ DEPS - the DEPS used for this gclient checkout commits.json - the pinned commits for Dart, flutter/engine, and flutter/flutter tools/ - scripts used to create monorepo DEPS engine/src/ - the flutter/buildroot repo flutter/ - the flutter/engine repo out/ - the build directory, where Flutter engine builds are created third_party/ - Flutter dependencies checked out by DEPS dart/ - the Dart SDK checkout. third_party - Dart dependencies, also used by Flutter flutter/ - the flutter/flutter repo
Flutter's instructions for building the engine are at Compiling the engine
They can be followed closely, with a few changes:
goma_ctl ensure_start is sufficient.Example build commands that work on linux:
MONOREPO_PATH=$PWD if [[ ! $PATH =~ (^|:)$MONOREPO_PATH/flutter/bin(:|$) ]]; then PATH=$MONOREPO_PATH/flutter/bin:$PATH fi export GOMA_DIR=$(dirname $(command -v gclient))/.cipd_bin goma_ctl ensure_start pushd engine/src flutter/tools/gn --goma --no-prebuilt-dart-sdk --unoptimized --full-dart-sdk autoninja -C out/host_debug_unopt popd
The Flutter commands used to build and run apps will use the locally built Flutter engine and Dart SDK, instead of the one downloaded by the Flutter tool, if the --local-engine option is provided.
For example, to build and run the Flutter spinning square sample on the web platform,
MONOREPO_PATH=$PWD cd flutter/examples/layers flutter --local-engine=host_debug_unopt \ -d chrome run widgets/spinning_square.dart cd $MONOREPO_PATH
To build for desktop, specify the desktop platform device in flutter run as -d macos or -d linux or -d windows. You may also need to run the command
flutter create --platforms=windows,macos,linux
on existing apps, such as sample apps. New apps created with flutter create already include these support files. Details of desktop support are at Desktop Support for Flutter
Tests in the Flutter source tree can be run with the flutter test command, run in the directory of a package containing tests. For example:
MONOREPO_PATH=$PWD cd flutter/packages/flutter flutter test --local-engine=host_debug_unopt cd $MONOREPO_PATH
Please file an issue or email the dart-engprod team with any problems with or questions about using monorepo.
We will update this documentation to address them.
flutter commands may download the engine and Dart SDK files for the configured channel, even though they will be using the local engine and its SDK.gclient sync needs to be run in an administrator session, because some installed dependencies create symlinks.