"I’m no longer hosting a fork of the main repository, instead favouring a fresh clone of the upstream repository on each build, and applying patches and overlays where needed to make the code build for our targets. The hope here is to make our build system more resilient to changes in the upstream repository so as to avoid manual intervention as much as possible."
How is this better than a fork? Git seems like it would handle merges much better than this DIY patch pile.
Sorry for the late reply, was at NIDevConf yesterday and only just got a look at this.
I agree - I was originally doing this with rebases. The problem I ran into over time was that because things upstream were changing around without my knowledge (which they should), files would move and the replayed steps would break. Even worse was when the rebase would succeed due to no merge conflicts, only to find out later on that the code file is now jibberish as the core team have taken a different direction earlier in the file / in an import / removed a variable etc.
I could have gone through and manually worked around this, but so much was changing, and so quickly (which is a good thing) that it was an uphill battle.
It's also possible that this is a solved problem in git rebase that I'm not aware of (I'm far from an expert), but by that point I'd kind of come to the realisation I was doing it wrong anyway (hacking together multiple Ubuntu versions, pulling packages from different releases etc.)
I now have a docker container I've put together that I intend to expand on (it's "cobbler" in my github, and referenced from this project) that builds the toolchain as a layer over Xenial - this takes a lot of the other hackery out of the equation.
It's beside the point but given that the goal of this when I set out was better tools on ARM and Chromebooks, I'm hoping to expand the docker image out to all of the architectures that debian supports (should be trivial) with static user-space QEMU enabled for all of them with mounted binfmt support (less trivial, but privileged mode should make it doable) - the idea being that adding a foreign architecture for something that's already building on Travis / Circle / Gitlab etc. should be as simple as "switch-arch arm64" before compiling and testing. Obviously, this assumes no exotic platform-specific calls.
Sorry for the rambling response, and thanks for the question.
It looks as though the code-oss binary in the ARM64/aarch64 packages is actually a 32 bit executable (code-oss: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=14b6a9ab1263520c73d76aafa59a326d291a44f8, stripped)
I'm making slow progress through the build system to work out what needs to be done - others are likely to be faster than I!
This is true - Electron currently doesn't support ARM64, so I wanted to get this to the point that it will be trivial to change at this side (which it now is) when they have it ready over there.
I wanted to have arm64 packages out in the meantime that people could use now - Electron will run as a 32-bit executable, but everything else (like the native extensions) are compiled to ARM64 (things like Oniguruma and node-gyp) to reap whatever benefits can be had from ARMv8 on those devices.
It also means that if/when Electron starts shipping ARM64 binaries I can switch over without breaking anything (users would likely not even know unless they had your shell savvy-ness!)
Edit: By the way, if you're looking for a starting point check out Chromium Embedded Framework (CEF), that's where we'd need to start with building out ARM64 support last I looked (then Electron, then this project).
Cool, thanks. I was trying to run the tool on one of Packet.net's ThunderX servers, which have no 32-bit support in the CPU itself. I'm grateful for your kudos, but it might be misplaced - I wouldn't have engaged my shell-foo if it had run :)
Will take a look at CEF, though my dev skills have atrophied in recent years.
Honestly, it looks like CEF is in good shape to build for ARM64, I just don't know anyone that does currently (it's a looooong build - so it rules out CI I think)
How is this better than a fork? Git seems like it would handle merges much better than this DIY patch pile.