Experiment: Negative on Electron on Yocto

Daniel experimented with building Electron under Yocto, for work. This turned out to be impractical for them, but he created some useful bits in the process.

Daniel works for Ambient Activity and experimented with building Electron under Yocto in order to build a new firmware for the ABBY. It turns out that ElectronJS is too bloated, and has too many moving parts, for small team use in embedded Linux.

The resulting open source codebase emanating from this project may be found at: https://gitlab.com/danielfdickinson/yocto-failed-electron.

From the README for that project’s attempt to build ElectronJS for the Raspberry Pi 5, which was chosen as an easy prototyping platform:

Results

It turns out Electron is huge and has a very large number of dependencies that have been modified from upstream and are therefore must also be downloaded and managed in order to build Electron.

In addition Electron’s developers actively discourage building from source and are not supportive of attempts to build from source.

Further, attempting track the licenses of the myriad dependencies in an automated fashion, as is built into Yocto, is time-consuming and not supported.

This makes ElectronJS an unsuitable project for embedded development, where there tends to be per-device configuration, and therefore limited or no ability to use the prebuilt binaries supplied by the ElectronJS project.

But some useful bits

Fixes and tweaks for building mixed open source / proprietary firmware

In the process of making this attempt, the author Daniel F. Dickinson created a meta-miscfix-mixins layer which makes it easier to create a Yocto-based firmware that does not have any GPLv3 or LGPLv3 code. This is important (along with avoiding similar licenses) because those licenses include the condition that all the code which in the firmware has to be released under the same license. This is problematic when the code is intended to be proprietary.

Parts of the project (like this repository) which are derivatives of the original open source code are not a problem to release, and in fact doing so continues to be a requirement of much of the code base’s licensing.

Some interesting code to pre-patch a codebase with supplied patches

Electron includes a number of patches on upstream projects, and these need to be applied in order for the upstream project to be usable for Electron’s purposes. So we develop a means to apply Electron’s patches to it’s upstream sources (pre-patch) that is reliable and doesn’t require pulling the patches into the Yocto build. (That would create a huge patch maintenance burden).

This method also maintains the ability to apply Yocto-specific patches on top of Electron’s patches and code.

…

Builds a modified Poky reference image

Building core-image-x11 results in the build of a Poky reference image which launches a rootless X server with xterm pretending to be matchbox-terminal, and busybox ash pretending to be bash.

This is done since matchbox-terminal and bash are both GPLv3 licensed, and we want to avoid that.

Explaining the tweaks

If you would like the author to provide more detailed explanations of the Yocto tweaks, please send him a note so he knows there is interest.