cbrake

Thanks for the detailed explanation!

Agreed, building on the typical target is a terrible idea. None of my suggestions are to build on target, but rather specific units on some capable hardware of the same architecture. The main build will still run on your own workstation of any architecture. Only specific units get farmed out to another machine, but worst case can be run in QEMU user mode emulation if there is no native machine runner available.

This remote build runner is not implemented yet, just ideas.

Is this similar to QEMU user mode emulation?

Thanks, I was not aware of this - will look into this more.

There are several ways to compile for the target:

1) Cross compile. Yoe build still does this where it makes sense. (Go apps, likely kernel builds in the future) 2) QEMU user mode - 5-20x slow, but fine for some things. 3) Run yoe-build on any ARM machine (AWS, rPI5, Jetson) 4) Farm unit builds out to runners on cloud ARM machines. (future)

The yoe-build architecture allows for this. Choose the container, host architecture, and location that makes the most sense on a unit-by-unit basis.

Caching is also part of the vision, so we never rebuild something twice, unless it changes.

I’ve been experimenting with what a next-generation embedded Linux build system might look like: native builds on the target architecture, modern language package managers as first-class citizens, and AI as a primary interface to the system.

Instead of cross-compiling with a large meta-layer stack, the tool builds kernel, rootfs, and applications together using one engine, with a CLI, TUI, and AI assistant talking to the same core. All you need is the tool, Docker, and Git — no global SDKs or hidden state.

It’s pre-1.0 and rough around the edges; I’m sharing it early to get feedback from people who live in Yocto/OpenEmbedded, Buildroot, Nix, etc. I’d love to hear where this breaks on your boards, what workflows feel wrong, and whether the “native builds + AI-aware build graph” direction seems promising.

For me, it is a lot simpler to host at Linode (or simpler) than figure out the AWS/GCP crazy complex IAM stuff.

However, there are cases where being able to spin down the server, and not pay for downtime is useful - like 36-core Yocto build machines.

I tried this yesterday and set it up for my wife. I was amazed at how many birds it picked up. There must be some amazing technology in the audio processing.