[junon]

Right now struggling to separate out architecture-agnostic code and architecture-specific stuff in a way that can be switched out with `--target` and still undergo LTO as though it were all inlined.

Cargo recently got multi-target builds which is great, and makes this way less of a headache before (usually had to run cargo once per target, now it can do all of them at once).

The next challenge is packaging things up. Cargo gives you a hook for running things prior to the actual crate compilation (e.g. using it plus graphicsmagick to generate a bit font for the boot sequence rasterizer) but lacks the ability to run anything after the build, which means no development disk image building or any image checking can occur without a second command.

There's an open issue tracking this with countless use cases but the cargo team seems reluctant to "replace build systems" (which is ludicrous to me).

[kibwen]

> Cargo recently got multi-target builds which is great, and makes this way less of a headache

Are you referring to Cargo's unstable "bindeps" feature? I ask because my company's the one that sponsored that work, and for the purposes of eventually stabilizing that feature we'd like to get feedback from users who are using it. :)

[junon]

Nope. Multi-Target is where you can specify an array for build.target in .cargo/config, or multiple --target options on the command line. It just got moved out of unstable into stable about a month ago.