Fixed: fxbug.dev/64153
Note that I also removed the TODO for fxbug.dev/86941. After talking
with the bug author, this file is not directly relevant to that bug.
This might not be necessary since we ultimately want to
get rid of these rules in favor of using the SDK, but it's
useful to me for reference during embedder prototyping.
I got rid of some arguments that seemed dead:
- `cml_file` in `_fuchsia_archive` didn't seem used anywhere. It is
used in `fuchsia_archive`.
- `meta_dir` didn't seem used.
Infrastructure runs the pm command on packages in a different path
which we were not accounting for. This will make sure we stamp the
packages when infra builds them.
Users can add an expose_dirs entry to the program field in a
component's cml file to optionally expose extra directories
from their out/ directory.
BUG: fxbug.dev/89690
BUG: https://bugs.fuchsia.dev/p/fuchsia/issues/detail?id=87813
As part of the fuchsia platform versioning we are stamping all of
our packages with a target api level which can be read by our assembly
tools. We would like to be able to update the target api level with a
roller so I added a file which can is read by the gn tool. I am open
to suggestions about how to change this is we do not want to add
file read calls to our gn script.
The initial implementation tried to leverage the fuchsia.git approach to
adding resources via GN template, but the GN SDK does not use the same
format or approach. This PR adds the snapshot resource in the way the
GN SDK expects.
The integration test works in debug/jit mode only, and building in
`profile` and `release` modes was not working, breaking some builders.
The workaround was to disable the test.
This PR will enable release/aot mode so it will build, and unblock both
the debug-mode version of the test (tested by CI) and release mode
builds of the repo.
Due to the request to unblock, this PR does not yet build packages in
`profile` mode that will run in Fuchsia, but it should at least build
without errors. Ongoing work is in progress to also support running in
release mode.
Bug: fxb/79871
The code is still using the CFv1 implementation, so this should not affect the existing behavior.
For this version of the PR, I forked the existing DartComponentController. There were a few reasons for this:
Reduces the chance of the change breaking existing tests during Fuchsia GI.
Makes the V2 version of the DartComponentController simpler to read.
Makes it easier to switch over to using the V2 version of the DartComponentController once the migration is ready to happen (less cleanup).
The rate of changes to the DartComponentController is slow so there shouldn't be much maintenance required for the fork.
Changes to the DartRunner itself will happen in a follow-up PR - this PR only verifies that the ComponentController builds.
Relands GN and C++ changes for #27226 after rollback in #28036.
Bug: 79871
Partial re-land of #27226 (which was reverted in #28036 due to a flaky test). Only adds in the CML files for a CFv2 dart_runner without the corresponding C++ and GN changes.
This reverts commit 1e9b7aed566105eec982ca0eb545139b218bc916.
Reverting in order to land revert of the gn script_executable from
python3 to vpython3, which is causing flakes on Windows.
Issue: https://github.com/flutter/flutter/issues/88719
Migrates all `#!/usr/bin/env python` hashbang lines to use python3.
Also updates the licence tool to treat python3 scripts on par with
python 2 scripts.
Issue: https://github.com/flutter/flutter/issues/83043
This PR also wraps up the soft transition for #27417.
Because some unit tests depend on the real Scenic which isn't hermetic, `flutter_runner_tests` and `flutter_runner_scenic_tests` aren't currently compatible with cfv2.
This will change once a FakeScenic is created (https://fxbug.dev/79873).
See https://fxbug.dev/79691.
Adds support for running the dart runner as a CFv2 component.
The runner has been refactored to launch in both a v1 environemnt
as well as a v2 environment.
This patch is in preparation for incremental package serving from the engine repo.
fxbug.dev/76633
Previous attempt to land this patch was failing because I was generating
the package manifest in the package's directory.
Currently, the licenses are copied into the bucket just before
uploading it. Copying the licenses is definitely more about "building"
the bucket than it is about "processing the CIPD package", but
concretely, some tools complain if the license files arent there, and
I'd like to be able to use the cipd tool to upload the bucket
directly.
Co-authored-by: Hunter Freyer <hjfreyer@google.com>
Example before:
$ ./tools/fuchsia/build_fuchsia_artifacts.py \
--engine-version HEAD \
--no-lto \
--archs x64 \
--runtime-mode debug
Running gn for variant "fuchsia_debug_x64" with flags: --fuchsia,--fuchsia-cpu,x64,--runtime-mode,debug,--no-lto
Generating GN files in: out/fuchsia_debug_x64
Done. Made 1085 targets from 221 files in 532ms
ninja: Entering directory `/usr/local/google/home/hjfreyer/flutter/engine/src/flutter/tools/fuchsia/../../../out/fuchsia_debug_x64'
ninja: error: empty path
Traceback (most recent call last):
File "./tools/fuchsia/build_fuchsia_artifacts.py", line 391, in <module>
sys.exit(main())
File "./tools/fuchsia/build_fuchsia_artifacts.py", line 380, in main
args.targets.split(","))
File "./tools/fuchsia/build_fuchsia_artifacts.py", line 283, in BuildTarget
BuildNinjaTargets(out_dir, [ 'flutter' ] + additional_targets)
File "./tools/fuchsia/build_fuchsia_artifacts.py", line 72, in BuildNinjaTargets
os.path.join(_out_dir, variant_dir)] + targets)
File "./tools/fuchsia/build_fuchsia_artifacts.py", line 55, in RunExecutable
subprocess.check_call(command, cwd=_src_root_dir)
File "/usr/lib/python2.7/subprocess.py", line 190, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['ninja', '-C', '/usr/local/google/home/hjfreyer/flutter/engine/src/flutter/tools/fuchsia/../../../out/fuchsia_debug_x64', 'flutter', '']' returned non-zero exit status 1
Co-authored-by: Hunter Freyer <hjfreyer@google.com>
Used the the `misspell` tool available at
https://github.com/client9/misspell, then applied hand-corrections. It's
possible we could adopt this as a presubmit, but there are still enough
false positives that it may not be worth the effort.
