Release Engineering Is Exhausting So Here's cargo-dist!

Helping your Rust projects ship prebuilt binaries that others can actually use without you having to become a Github CI Expert (or Rust Toolchain Expert) ((or OS integration expert)) (((or...)))

https://blog.axo.dev/2023/02/cargo-dist

axo blog - Release Engineering Is Exhausting So Here's cargo-dist

Release Announcement for cargo-dist, a tool to help you package up binaries for a Rust application.

@Gankra Niiiice.

You mentioned thinking about SDKs etc and controlling deployment version, what is the plan for your platforms (especially building somewhere new-ish and deploying to older versions)? MacOS seems to at least have sdk controls in its toolchain (maybe not for Rust?), windows iirc has symbols you define, and linux usually requires a sysroot, or is the situation a lot nicer in Rust-land than C++ land?

Also, on the topic of "old glibc", passenger's holy-build-box should be a possibility, but I'm not sure it's optimal when you need to install so much new-ish toolchain.

@lenary unfortunately I only know about the Problems and know nothing about the solutions, help definitely wanted, because I want cargo-dist to help with this for sure!

https://github.com/axodotdev/cargo-dist/issues/78

target sdk version support · Issue #78 · axodotdev/cargo-dist

When making prebuilt binaries you "need" to decide how old of a system you're willing to support. i.e. if you want to rely on APIs introduced in windows 10, your binary won't nece...

GitHub
@Gankra I am happy to drop some thoughts/pointers in that issue for you!
@lenary please do! 🙇
@Gankra well, of course i hit submit 30% of the way into the comment, but it's updated now. I couldn't find one link I wanted to, I'll have to ask someone else what to do there.
@lenary this definitely helps -- also it's nice and reassuring to know that there wasn't an obvious "it's easy" approach I was missing x3

@Gankra I've had to firefight now a few different upgrades at work: a surprise "oh shit one of our testing deps needs a better glibc so someone updated a docker image, and now we can't ship to customers on older linuxes", and another surprise of "this source file no longer compiles with very old gcc, we need to update our whole build tree, including static library dependencies" and tbh, I opted out of thinking deeply about this a third time for Windows as I am not actually a build expert, just someone who tries to pay attention and knows this stuff is harder than one would hope.

My best advice is never to undervalue the ability to rebuild your whole dependency tree from source, which is sometimes an easier way to get yourself out of an ABI difficulty than any other way. Rust is young enough this should still be doable. It isn't with C/C++.

One thing I specifically didn't cover was lots of the random bullshit to do with packaging C++ apps, where you have to learn that it is not the case that gcc and clang C++ objects can always be linked together, or even objects from two different versions of the same compiler without greater care than you want to know.

Actually, now I think about it, there's even C11 objects that can easily not be compatible between gcc and clang, but in that little corner of the compiler (atomics) I can also find issues linking Rust code to C/C++ code.

@lenary yeah the ABI issues between compilers fucking suck, that's why i made https://github.com/Gankra/abi-cafe

(still need to get back to v2 on that...)

GitHub - Gankra/abi-cafe: Pair your compilers up at The ABI Café!

Pair your compilers up at The ABI Café! Contribute to Gankra/abi-cafe development by creating an account on GitHub.

GitHub
@Gankra this is all ABI! We are cursed to think about the hardest problems in toolchains forever.