Eliminates the `strip_bitcode` GN rule defined in
//flutter/sky/tools/mac.gni and the related script at
//flutter/sky/tools/strip_bitcode.py.
As of Xcode 14, bitcode is deprecated, no longer enabled by default, and
generates a warning message if a project enables it. Bitcode support
will be removed entirely from a future version of Xcode.
The `strip_bitcode` rule had two purposes:
1. Copy the binary specified by its input parameter to the path
specified by its output parameter.
2. Strip bitcode segments as it does so.
While we no longer require the second of these functions, we still use
the first to create a `gen_snapshot` binary suffixed with the target
architecture. This replaces `strip_bitcode` with the built-in gn `copy`
rule instead.
Issue: https://github.com/flutter/flutter/issues/107884
Issue: https://github.com/flutter/flutter/issues/112896
Issue: https://github.com/flutter/flutter/issues/101138
Issue: https://github.com/flutter/flutter/issues/103386
The gen_snapshots.py tool is used to copy an input gen_snapshot to an
output path with an architecture-specific suffix. For example, to copy
gen_snapshot to gen_snapshot_arm64. Bitcode segments, if any, are
stripped.
This moves the input/output filename hardcoding into the BUILD.gn file
and generalises the logic to simply copy an input binary to an output
path with bitcode segments stripped. Since the tool is no longer
gen_snapshot specific, we rename it from gen_snapshots.py to
strip_bitcode.py.
This also renames the generalised `macos_gen_snapshots` rule to
`strip_bitcode`.
Since we're working on removing bitcode support from the engine, this
script will eventually serve no purpose other than to copy the input
binary to an output path, at which point this script, and the associated
`strip_bitcode` template in `//flutter/sky/tools/macos_tools.gni` can be
removed.
Along with the TODO, renaming the script and the rule help ensure we'll
spot this and remove it when bitcode support is removed from the engine.
Finally, this fixes a dependency issue in the target
//flutter/lib/snapshot:create_macos_gen_snapshots. Previously, it
dependended on ":generate_snapshot_bin", but in fact, the only file it
touches is gen_snapshot. This was built transitively as part of the
":generate_snapshot_bin" target, but is now depended on directly.
This is pre-factoring for merging the iOS and macOS gen_snapshot
creation build rules in `flutter/lib/snapshot/BUILD.gn`.
Issue: https://github.com/flutter/flutter/issues/103386
Issue: https://github.com/flutter/flutter/issues/101138
Issue: https://github.com/flutter/flutter/issues/107884
create_macos_gen_snapshots.py uses `xcrun bitcode_strip` to copy
gen_snapshot from its build directory to a suffixed gen_snapshot_arm64
or gen_snapshot_armv7, while stripping the bitcode segment, if any.
This simplifies the python invocation to use subprocess.check_call, and
also guarantees the process exits with failure in such a situation --
we weren't checking the return value of generate_gen_snapshot.
This is cleanup for issues encountered while working on merging
macOS/iOS gen_snapshot tooling.
Issue: https://github.com/flutter/flutter/issues/103386
Issue: https://github.com/flutter/flutter/issues/101138
Towards implementing the FragmentProgram API in Impeller.
Specifies an Impeller specific format for data the renderer can use to create
pipelines with user supplied shader stages at runtime.
The data is in the form of a flatbuffer with a known schema.
This patch implements the wire format, creating and loading the program
payloads, and creating pipeline state objects using these payloads.
If the user supplied SPIRV intended for the older API, the loader will reject
this invalid payload. This is probably not going to be too much of an issue
because the FragmentProgram API will probably be modified to only allow buffers
loaded from asset managers. But still, in the meantime, I am using the old API
to pass these new buffers.
Fixes https://github.com/flutter/flutter/issues/104750
Fixes https://github.com/flutter/flutter/issues/105542
Towards resolving https://github.com/flutter/flutter/issues/102853