I am not sure if we should land this. We ought to already support this via the custom toolchain integration with GN. So folks who need these artifacts can already building them using their own toolchains. Adding support here will mean that we need to maintain these rules and test them (perhaps on even add recipes to pre/post submits). Do do this for artifacts that we don't actually vend makes me hesitant to endorse this.

We ought to already support this via the custom toolchain integration with GN. So folks who need these artifacts can already building them using their own toolchains.

That's true, it's already possible to build the engine that way. The article you wrote is really helpful for that, helped me when I started at least. But building the engine that way is difficult to maintain and also not as straightforward. The former is actually the reason for these PRs, the update to clang 13 broke my build scripts that bad that it seemed easier to just fix it in the engine.

Some things that complicate the custom toolchain build method:

• you have to use exactly the right version of clang (if you use newer clang, it'll throw some additional warnings that aren't ignored yet by the build scripts, if you use older, some -Wno-<warning-name> generated by the build scripts will be unrecognized by clang).
• Libcxx and libcxxabi can no longer be built seperately anymore as easily, as done in the article
• When you copy over the sysroot, you'll probably have to fix dangling absolute symlinks
• Not sure that bug still exists, but the pkg-config script didn't look for the GTK+ pkgconfig in the right directory with the copied over sysroot

When it's supported in the engine, all those problems will just be gone and you can just do flutter/tools/gn --linux-cpu arm.

Adding support here will mean that we need to maintain these rules and test them (perhaps on even add recipes to pre/post submits). Do do this for artifacts that we don't actually vend makes me hesitant to endorse this.

I'm currently working on a CI shard for building the armv7 engine, that's the way hixie recommended for testing this PR. I think the build didn't break that often in the past 2 years. IIRC it broke two times: one time when you started using pkg-config to look for gtk+ and one time when ARM64 support was added. Both have pretty trivial fixes. So I think the maintenance burden shouldn't be too high.

you have to use exactly the right version of clang

You should be able to plug in engine supplied toolchain as a custom toolchain via --target-toolchain. That should fix all the issues you had with the Clang version selection.

Libcxx and libcxxabi can no longer be built seperately anymore as easily

That part of the article is outdated and you no longer need to build these yourself. The buildroot will build these using the toolchain you provide to it.

Oh, that's good to know! I guess this PR is more of a syntactical change then

@KDAB would also be happy to maintain the armv7 support in the engine / CI and help fix any problems, if it's merged.

cc @zanderso

Our goal with armv7 is currently to make sure that we keep the custom toolchain and sysroot configurations working, so at the moment, I don't think we can accept this PR. Instead, we should focus our energies on making sure that the flow that we can support is well-tested: flutter/flutter#90833.