For professional embedded development, where reproducible-in-the-future builds are frequently valued, it's common, when possible, to set up your whole toolchain in a vm that's kept under version control.

It is indeed possible to make a nice container that contains a program, offers a clean interface to that program, and doesn’t package a whole pile of largely irrelevant, guaranteed-to-be-quickly-outdated crap with it.

But being possible doesn’t mean that anyone does it. Most containers I’ve ever seen are big messes. Possibly GPL-violating messes if the payload isn’t appropriately licensed. Certainly maintenance and provenance disasters. Unquestionably not reproducibly buildable and possibly not buildable at all.

> and doesn’t package a whole pile of largely irrelevant, guaranteed-to-be-quickly-outdated crap with it.

> Possibly GPL-violating messes if the payload isn’t appropriately licensed. Certainly maintenance and provenance disasters. Unquestionably not reproducibly buildable and possibly not buildable at all.

If static binaries are on the table then none of these things can possibly be disqualifiers.

Yes, I used to do that for a couple of projects, but it wasn't as smooth as I had hoped. For instance I had a bunch of challenges getting USB stuff to work properly. And there were some tools that still required me to lug around a windows laptop for parts of the process.

I'd much rather have proper tooling to begin with rather than have to pull out everyone's favorite roll of duct tape (Docker) to hide the mess.

Docker is great if you don't care about your build performance across a wide range of hosts, it's probably fine for small projects but I've seen incremental build times climb quickly where docker support wasn't the best(i.e. OSX).

You mean, where native Docker support is completely absent, and the whole thing has to rum in a VM?

Well, OSX and Windows run it in a VM, so there you have it.

I meant it as in having a CI system that relies on Docker or whatever container image system. You submit a build via some config files, the build farm builds the image and extracts the built binaries into a repo/binhost/S3, and you get your binary from there. Or you can now use that image for another build, in a pipeline.

There’s zillions of options for doing this nowadays, many of them self-hostable, which is pretty cool.