You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#278 spun down our remaining clang-10 tests. I'm curious if it's worthwhile to keep some arm64 + x86_64 builds going for branches of stable with clang-10? We can probably look and see what clang versions various Android releases are using.
The text was updated successfully, but these errors were encountered:
I was thinking more about this within the context of #278 and I am not sure there is much value in continuing to build with clang-10.
We don't have any avenue to fix bugs in the compiler because it is not supported anymore (one of the main reasons we bumped to clang-11 on mainline).
If something breaks in stable for one reason or another, inserting workarounds into the source is not going to be easy without them being upstream (the stable hates taking patches just for stable).
Right, but clang-10 was supported when those branches of stable were created, and Android is still using clang-10 based versions of AOSP Clang. Having some heads up when stable takes a patch that might break these older LTS branches that have yet to go out of support might be worthwhile. We'll find such cases either way in Android though.
Fair enough, I thought that the most recent version of Android had kernels compiled with clang-12 but I guess there could be other targets or older branches that matter? What branches should we support here with clang-10 and what kind of build targets are interesting?
#278 spun down our remaining clang-10 tests. I'm curious if it's worthwhile to keep some arm64 + x86_64 builds going for branches of stable with clang-10? We can probably look and see what clang versions various Android releases are using.
The text was updated successfully, but these errors were encountered: