For my own programs build from scratch, I use mostly build on target itself. It are only a few source files and as gcc is so standard in Linux, I have it always installed. Result I copy to a dedicated on path on rootfs. Might be with help of script to avoid a lot of repetitive actions. Those own programs are all HW and I/O related, so also for an initial test, they need to run on target HW anyway.
For the rest, I almost build no application/userspace SW anymore nowadays. All is there to download already from distro repos etc. If a certain program is too old version, I just jump to other distro, rolling release. That is usually only a month behind source code commit. I use Opensuse Tumbleweed mainly, also Debian Testing (Forky now), although not at the moment, have other things to figure out first.
For builds that do take more than a few seconds or a minute, it makes sense to do that on fast computer. Does not really matter how, but I use KVM sometimes (4x Cortex-A76, 8GB) or systemd-nspawn container just on the whole (cloned) rootfs of the target machine. That makes sense for RPi0/1 and those require Raspbian (not Debian armhf) and an ARM64 buildhost is 100x faster, even more if Apple M1 or so. I also made rootfs of RPi0/1 such that it also runs as KVM on a fast ARM64 computer, so I just copy/clone differences back to real HW.
So kernel and bootloader compiles/buids I do not on target as it would take days instead of an hour. Kernel builds with Armbian build for example produce a .deb package that can be installed in 1 step with sudo apt install ./<.deb package>. But I also have own scripts to put bootloader and kernel in the right places on the target. W.r.t. RPiOS, the RPL methods used in rpi-update script are incompatible with generic (Debian) Linux, I can't use those.
For the rest, I almost build no application/userspace SW anymore nowadays. All is there to download already from distro repos etc. If a certain program is too old version, I just jump to other distro, rolling release. That is usually only a month behind source code commit. I use Opensuse Tumbleweed mainly, also Debian Testing (Forky now), although not at the moment, have other things to figure out first.
For builds that do take more than a few seconds or a minute, it makes sense to do that on fast computer. Does not really matter how, but I use KVM sometimes (4x Cortex-A76, 8GB) or systemd-nspawn container just on the whole (cloned) rootfs of the target machine. That makes sense for RPi0/1 and those require Raspbian (not Debian armhf) and an ARM64 buildhost is 100x faster, even more if Apple M1 or so. I also made rootfs of RPi0/1 such that it also runs as KVM on a fast ARM64 computer, so I just copy/clone differences back to real HW.
So kernel and bootloader compiles/buids I do not on target as it would take days instead of an hour. Kernel builds with Armbian build for example produce a .deb package that can be installed in 1 step with sudo apt install ./<.deb package>. But I also have own scripts to put bootloader and kernel in the right places on the target. W.r.t. RPiOS, the RPL methods used in rpi-update script are incompatible with generic (Debian) Linux, I can't use those.
Statistics: Posted by redvli — Fri Jan 02, 2026 9:56 am