Use ubuntu-22.04-arm host instead of ubuntu-22.04 for aarch64 builds

[HinTak]

Looks like even with qemu, aarch64 on aarch64 is 10x faster than aarch64 on x86_64. This is not a reverse of #189 , but just running aarch64 qemu on aarch64 (different ubuntu releases).

Mostly just as a timing test, but could merge as is, or further reversal of #189, if it goes well.

Cc @lucach @kyamagu

[HinTak]

I have added a simple one line change to v87 and the build skia step (before it was split into 3rd party + proper) went down from 2 hour 34 min to 6 min. I.e. aarch64 on aarch64 is about 25x faster than aarch64 on x86_64!

[HinTak]

It finishes in just over an hour. Will add some simplifying changes as per #315

[lucach]

Impressive speed, indeed! Thanks for the work and, of course, no objections to removing the workarounds/hacks introduced in #189.

[HinTak]

It looks like native builds on aarch64 hosts take similar enough time as x64_64 hosts as far as github CI goes. We can remove all the cache management code in the CI yaml and the staged build stuff in build_Linux.sh .

[HinTak]

The overall speed is about 1 hour 20 min for a complete set of wheels, and with this pull we just build aarch64 wheels like the others - aarch64 linux isn't the slowest. The timings are not consistent, mostly it is similar enough to x86_64 Linux or arm64 mac (which is similar to x86_64 mac) to not stand out and look different from the other 3.

We still build gn from source, but that's available from Linux these days, so probably something to look into.

[HinTak]

Using el8 shipped ninja and gn works for current skia, but definitely not m87 (m87 definitely needs the older version of gn, hence we checked out a specific version and compile it in m87). The skia build system also does something quite weird in downloading ninja and gn binaries from google servers for specific platforms. This was also not available for aarch64 linux in m87 (the download scripts checks current arch, and did not include aarch64 then).

So this is a bit flaky - using current ninja and gn with current skia works (as long as we keep updating skia), and m87 must use old gn, which means at some point we might need to patch the older gn for newer compiler... you'd have thought ninja and gn are somewhat stable now.

The ci build machinery in the m87 branch is kept in sync with this except the gn issue. I tried patching m87 for newer gn but gave up after the 3rd patch and reset the branch. @pavpanchekha

[pavpanchekha]

Thanks for the update, Hin-Tak. Does this mean it's hard to produce aarch64 builds of m87, or just that we have to stick to an x86 host for that?

[HinTak]

@pavpanchekha yes, aarch64 build of skia m87 is hard to do. Let me see if I can explain it briefly:

• the complexity depends on 3 things: the skia code itself, the build host (compiler and runtime), and google build tools, gn and ninja - roughly equivalent to autoconf ( those ./configure ... you often do with other software) and make.
• as a preparation step, skia's git-fetch-deps besides downloading up to a few GB of dependency, also download specific version of specific platform binaries of gn (recently also ninja).
• google host 6 x platform and versioned binaries of gn and ninja these days ( x86_64, arm64 × mac,win,linux).
• google did not provide aarch64 binary of gn until much later.
• so we have been building old version of gn for aarch64, and it is getting harder as we move compiler/host, in addition and before building old version of skia with newer compiler/host.

Newer linux actually comes with somewhat recent version of ninja and gn, and they are sufficient to build current skia; so that removes one complexity of dealing with building the google build tools themselves.

Anyway, to cut a long story short: I wrote in #312 one patch is needed to update skia m87 itself for "not too old" compilers/hosts (this is now included in v87.8). It looks like a 2nd patch is needed for "current" compilers/hosts. Two more patches are needed to update m87 to use current gn, and a 5th patch to force m87 to use current gn (instead of downloaded gn which fails for aarch64).

So it takes 4 additional patches beyond v87.8, one for newer compilers, 3 for sensitivity to specific old version of gn, to build m87 using current compiler and current-ish gn / ninja shipped by linux vendors.

current skia will likely always work with current compiler & current gn / ninja ; but the numbers of patches needed to build m87 with current compilers is likely to increase, and dependency on specific old version of gn (and having to build it and patch it) or patches for compatibility with current gn are going to be between two bad alternatives. I could only hope that gn and ninja become stable with time and sensitivity / requirement to specific gn /ninja decreases with time in general.

@pavpanchekha in a nutshell, it takes another 4 to 5 patches to build v87.8 as we do current skia with current tools here in this pull.

[kyamagu]

I have some thoughts on maintaining old skia packages. Any opinion there?
#316

[HinTak]

@kyamagu I was going to say we'll definitely stop m87 if/when somebody asks for arm windows builds (that's basically all the trouble with aarch64 linux builds, plus my lack of interests & expertise on windows...), and I was hoping that it isn't for some time yet - but there is a request now (linked in #318). I am happy to HAVE A LOOK at how painful it is to build skia-python m87 for arm windows, but definitely don't want to support that usage...

[HinTak]

Arm windows build failing with pypa/cibuildwheel#2364 , I think

[HinTak]

It seems that skia-python is failing at the numpy part of "pip install pybind11 numpy" in the build wheel requirement part.

[HinTak]

Argh, I have CIBW_BEFORE_BUILD: pip install pybind11 numpy which is failing at the moment.