3 ms·

Wouldn't Docker (or other container tools) be a good candidate? Instead of installing the toolchains locally, do the build on a container based on an image with

Wouldn't Docker (or other container tools) be a good candidate? Instead of installing the toolchains locally, do the build on a container based on an image with the exact toolchain you need.

bborud 2y ago
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.
amluto 2y ago
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.
- yjftsjthsd-h 2y ago
  > 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.
buescher 2y ago
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.
vvanders 2y ago
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).
- LtdJorge 2y ago
  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.
- nine_k 2y ago
  You mean, where native Docker support is completely absent, and the whole thing has to rum in a VM?
- petre 2y ago
  Well, OSX and Windows run it in a VM, so there you have it.

Wouldn't Docker (or other container tools) be a good candidate? Instead of installing the toolchains locally, do the build on a container based on an image with the exact toolchain you need.

bborud 2y ago

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.

amluto 2y ago

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.

yjftsjthsd-h 2y ago
> 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.

buescher 2y ago

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.

vvanders 2y ago

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

LtdJorge 2y ago
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.
nine_k 2y ago
You mean, where native Docker support is completely absent, and the whole thing has to rum in a VM?
petre 2y ago
Well, OSX and Windows run it in a VM, so there you have it.