* Generate fonts in the expected location.
Fonts-subset is generated directly in out/../zip_archives but the final
destination is expected to be inside a folder like linux-x64. This PR
generates the file directly in the expected path.
Bug: https://github.com/flutter/flutter/issues/81855
* Fix font zip tests.
* Revert changes to run_tests.py
* Update host_os_cpu_name variable to report darwin for mac.
* Fix variable names.
* Calculate prebuilts path using mac instead of darwin.
* Add platform to fontset path.
* Fix platforms map.
* Add debugging.
* Add win32 to the map of artifact locations.
* Use full_platform_name instead of host_os_name.
* Use x32 for windows font binaries.
* Fix paths for debug version in windows.
* Use x64 for win32.
* Remove additional logging.
* Add linux2 to map of platforms.
This change will make Flutter's frontend_server validate that any kernel
file given to it was produced by the same Dart SDK hash as the
frontend_server itself is based upon.
Notice that this implies one cannot use the prebuilt Dart SDK's
frontend_server and give it kernel files produced in the current build
iff //third_party/dart is at a different SDK hash. (By-default the
prebuilt Dart SDK and //third_party/dart are based on the same git
commit hash)
=> This is mainly relevant for people who change //third_party/dart
during local development (e.g. for preparing rolls, ...)
=> In such cases one should pass "--no-prebuilt-dart-sdk" to
flutter/tools/gn
The effect of this change is that one will get a clear message on
mismatched kernel files instead of possibly an exception from the CFE.
The change is changing the Flutter build actions similar to how [0]
changed the Dart build actions.
Issue https://github.com/flutter/flutter/issues/92679
[0] https://dart-review.googlesource.com/c/sdk/+/152802
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.
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 converts the ci/format.sh script to a Dart script that uses process_runner and isolates to multi-process the clang-format, diffs, and grepping needed to do the formatting changes.
It also will (by default) only check the formatting of changed files.
The user can optionally check all files (--all-files) or do only some types of checks with --check. --verbose prints the versions of the tools used for Clang format and Java format.
Specifying --fix will cause any formatting errors that would have been detected to be fixed.
On a stock Ubuntu 19.10 system, the following deps are required, at
minimum:
* libx11-dev
* libxcursor-dev
* libxrandr-dev
* libxinerama-dev
* libxxf86vm-dev
* libgl-dev
This was only necessary when the Engine had to build in multiple buildroots
where the sources where checked out at different paths relative to the
buildroot. This is no longer the case and there are already cases GN rules
have been written that mix and match variable usage with the direct
specification of the path to the Flutter sources relative to the sole buildroot.
Rather than running the runloop forever, have the API expose an incremental runloop. This allows clients to do other processing if they need it.
This allows for removing the odd construction of having knowledge of GTK event handling built into the library even though nothing in the library uses it; instead runner applications that use GTK plugins (such as FDE's testbed) can do that processing at the application level instead.
Almost all of the python build files in the flutter project work if
`python` is `python2` or `python3`. This is the only area where print is
incorrectly used (for `python3`).
Related issue: https://fuchsia-review.googlesource.com/c/fuchsia/+/272925
Simplifies the build and runtime requirements for the Linux shell.
Since the engine does GL extension lookup manually anway, an extension
loader library isn't necessary.
