This makes subsequent runs much faster by allowing to skip compilation to Kernel at the cost of introducing a bit of spam into the output when it starts resident compiler for the first time. Seems like a fine trade-off for dev-mode command.
```console
$ time flutter-dev -h
...
________________________________________________________
Executed in 5.32 secs fish external
usr time 438.69 millis 0.09 millis 438.60 millis
sys time 111.91 millis 2.42 millis 109.48 millis
$ time flutter-dev -h
...
________________________________________________________
Executed in 579.14 millis fish external
usr time 433.87 millis 0.08 millis 433.79 millis
sys time 109.27 millis 2.57 millis 106.70 millis
```
Not so long ago I remember a very informal conversation that went something like this:
> @matanlurey: I wish I could pass `--dev` or something to `flutter` to run from source.
>
> @christopherfujino: I get what you want, but I don't want to overload the tool with more dev-only things. I would consider a script like `flutter-dev` that does that thing, though.
>
> @matanlurey: Cool, I might send a PR!
So uh, here it is 6-9 months later. Suggestions welcome.
Fixes https://github.com/flutter/flutter/issues/112833
Most of the actual changes here are in [packages/flutter_tools/lib/src/version.dart](https://github.com/flutter/flutter/pull/124558/files#diff-092e00109d9e1589fbc7c6de750e29a6ae512b2dd44e85d60028953561201605), while the rest is largely just addressing changes to the constructor of `FlutterVersion` which now has different dependencies.
This change makes `FlutterVersion` an interface with two concrete implementations:
1. `_FlutterVersionGit` which is mostly the previous implementation, and
2. `_FlutterVersionFromFile` which will read a new `.version.json` file from the root of the repo
The [`FlutterVersion` constructor](https://github.com/flutter/flutter/pull/124558/files#diff-092e00109d9e1589fbc7c6de750e29a6ae512b2dd44e85d60028953561201605R70) is now a factory that first checks if `.version.json` exists, and if so returns an instance of `_FlutterVersionFromGit` else it returns the fallback `_FlutterVersionGit` which will end up writing `.version.json` so that we don't need to re-calculate the version on the next invocation.
`.version.json` will be deleted in the bash/batch entrypoints any time we need to rebuild he tool (this will usually be because the user did `flutter upgrade` or `flutter channel`, or manually changed the commit with git).
Use the pub cache resolved by pub itself.
To add packages to the flutter.zip download they are packaged as tar.gz and added to the pub-cache on first run by using `pub cache preload`.
As the results of "uname -s" command is like the below on MSYS2 on
Windows Terminal,
MSYS_NT-10.0-22621
This patch fixes the Flutter command working on this kind of systems.
Signed-off-by: Deokgyu Yang <secugyu@gmail.com>
Signed-off-by: Deokgyu Yang <secugyu@gmail.com>
* Use `dart __deprecated_pub` instead of `pub` to invoke pub from tools
The top level `pub` commmand has been deprecated and will print
a message. It is however implemented via the __deprecated_pub command
that prints no message.
The CFE now logs to stdout by default when compiling a program which has
non-null-safe dependencies. Since flutter_tools has not yet migrated, we
need to suppress this message when compiling the tool.
Fixes https://github.com/flutter/flutter/issues/74366
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.
This makes the flutter and dart scripts invoke their batch file equivalents if running under MINGW (i.e. git-bash) on Windows.
This allows for proper locking, and makes sure that people aren't using two different (and non-mutally-aware) locking systems when running flutter on Windows.
I also fixed a couple of places where we look for MINGW32, which fails under MINGW64. It just looks for MINGW now.
This reverts the flutter command to use shlock when flock isn't available. It seems that the mkdir method isn't as reliable as we want. I think that this is because the trap isn't always be executed, which is why I think that shlock uses PIDs to help it be more reliable. Unfortunately, that means that we're back to not working over network shares (which is where things were before I moved to the mkdir method, so not really a regression). I did leave in the mkdir method for platforms that have neither flock nor shlock (which should be very few and far between, but still), so at least we'll do some locking there now.
