As of the following patches, we now bundle FlutterMacOS.framework.dSYM as part of FlutterMacOS.xcframework. The dSYM is automatically copied into the release build products directory, and bundled in the .xcarchive produced by Xcode's *Product > Archive* feature which produces bundles for upload to the App Store.
* https://github.com/flutter/engine/pull/54696
* https://github.com/flutter/flutter/pull/153975
The .dSYM bundle is now available both in the uploaded .xcarchive and in the xcframework in Flutter's internal artifact cache. For developers with CI toolchains that do additional manual handling or local archiving of .dSYMs, the dSYMs no longer need to be downloaded from cloud storage as previously detailed in `docs/Crashes.md`, but can instead be copied up from the appropriate dSYM subdirectory in the framework cache:
* `flutter/bin/cache/artifacts/engine/darwin-x64-release/FlutterMacOS.xcframework`
Also adds documentation for crash symbolication on macOS.
Issue: https://github.com/flutter/flutter/issues/153879
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Rather than editing `.ci.yaml` to enable the `linux_web_engine` shard, instead suggest tagging with the `test: all` label, which avoids the risk of accidentally committing an unwanted change to `.ci.yaml` and having to revert the change before landing.
This is also more future-proof against further `runIf` additions to `.ci.yaml`.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Most framework tests perform a `flutter precache` or rely on the web SDK in some form. The Web SDK is not build in presubmit by default. As such, developers will need to manually comment out the `runIf` conditional block that prevents the web SDK from being built during presubmit, then later hope they uncomment it before landing their patch.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Reverts flutter/engine#54453
Not quite ready to remove Impeller Scene yet because I'm still porting
the animation functionality. Keeping it around allows me to switch back
and forth to compare without having to recompile the engine.
Over a month ago I said something like "we can revert this a couple of
weeks from now" in one of the Impeller meetings. But for better or worse
(better, I think), I ended up spending a ton of time trying to make the
PBR good first (which doesn't exist in this C++ version).
This renames the iOS framework creation script for consistency with the analogous macOS script.
Previously, we had two iOS framework creation scripts:
* create_ios_framework.py
* create_full_ios_framework.py
The former was unused and was deleted in https://github.com/flutter/engine/pull/54227. The addition of "full" is no longer necessary to differentiate the two.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
In 2021, we did some experiments with ML-guided optimisations in the
engine. Ultimately, these didn't provide much benefit, and much of the
information in the documentation is now out-of-date.
For those who need it, this can always be found in the git history.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Document that when using RBE, users should ensure the locally installed Xcode toolchain version matches that of the bots, otherwise they're likely to experience slow builds due to cache misses.
Ideally, we should also check the value automatically against the `sdk_version` specified in the relevant `et` build config itself.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This PR changes from using a different GN pool for each non-compiler tool, to using one GN pool for everything.
Additionally, since we are no longer linking remotely in any configuration, this PR uses the pool for linking.
ObjC and impellerc tasks also do not (yet) run on RBE, so they are also now governed by the pool.
Needs https://github.com/flutter/buildroot/pull/856
## Description
This turns off the Doxyfile option `CREATE_SUBDIRS` because it prevents deep link URLs from being stable. It means that thousands of files will be in the main directory, but the filesystem should be able to handle that.
I got rid of the header/footer files for doxygen (because Doxygen will generate them anyhow) and fixed where it was looking for the Flutter logo.
I also ran Doxygen on the Doxyfile template and Doxyfile and updated all the options to correspond with the latest Doxygen.
