engine
engine copied to clipboard
flutter
Remove zlib from list of automatically automated dart roll dependencies
zlib can't be rolled forward in flutter engine due to mac ios simulator clang set up.
zlib need to be rolled forward in dart sdk to accompany updated clang and gn in dart sdk: https://dart-review.googlesource.com/c/sdk/+/248720
See https://github.com/flutter/flutter/issues/106352 for more details.
Gold has detected about 1 new digest(s) on patchset 3. View them at https://flutter-engine-gold.skia.org/cl/github/34226
Where is the Dart version of clang coming from? The Flutter version comes from what is pushed by the Fuchsia toolchain team to CIPD and is picked up by an autoroller e.g. here: https://autoroll.skia.org/r/clang-linux-flutter-engine. Why is Dart seeing this issue with a new clang toolchain from Fuchsia, but Flutter isn't?
Where is the Dart version of clang coming from?
https://dart-review.googlesource.com/c/sdk/+/248720 attempted to align dart clang with flutter/fuchsia one.
Why is Dart seeing this issue with a new clang toolchain from Fuchsia, but Flutter isn't?
Without updating zlib you get these kind of warnings:
[3283/3661] CC obj/third_party/zlib/chrome_zlib.gzclose.o
../../third_party/zlib/gzclose.c:11:13: warning: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
int ZEXPORT gzclose(file)
^
../../third_party/zlib/chromeconf.h:80:17: note: expanded from macro 'gzclose'
#define gzclose Cr_z_gzclose
^
1 warning generated.
Dart's clang comes from the same place, but is rolled manually / less frequently. (This means Flutter is usually using a toolchain that has not been tested with Dart, and recent bugs have been discovered when combining Dart with newer toolchains.)
Flutter is seeing this issue with the new toolchain and old zlib, but suppressed it instead of updating.
Could we both solve this the same way. That is, leave zlib where it is, update the warning flags in the GN boilerplate, and roll the toolchain forward in both places?
That is, leave zlib where it is
Strategically it seems to be a bad place to be in, especially considering recent need to roll zlib.
Do you have a sense how long we would be blocked from rolling zlib forward?
If there is a need to roll forward before we can upgrade Xcode, we'd have to fork the BUILD.gn file to supply our own compile flags. Another solution would be to track upstream instead of the chromium fork, or to switch over to something like https://github.com/zlib-ng/zlib-ng.
Okay, for now we landed https://dart-review.googlesource.com/c/sdk/+/249542 that keeps zlib as it was.
