
An automated assembly line for Visual Studio Code on ARM - headmelted
https://headmelted.com/what-i-learned-building-code-that-builds-visual-studio-code-b520b1d83d0f
======
krallja
"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.

~~~
headmelted
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.

------
timthorn
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!

~~~
headmelted
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).

~~~
timthorn
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.

~~~
headmelted
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)

------
crazysim
"Cron job"

Would the Travis CI cron job system work?

[https://docs.travis-ci.com/user/cron-jobs/](https://docs.travis-
ci.com/user/cron-jobs/)

~~~
headmelted
Actually I think I can make this work for me. Tagging doesn't seem to be
supported for Github releases, but I can work around it.

Thanks!

