Best practice for custom build steps that can't be handled by build scripts


#1

Is there any best practice or convention for how to automate build steps that can’t be handled by Cargo, even if using build scripts? For instance, with Cargo you can only change the libraries or library search paths passed in to rustc, but no other arguments. And with Cargo you can execute commands in the build script before you libraries and binary are built, but not after, so you can’t do any kind of post processing.

The simplest solution is, of course, to just have a Makefile or fill-in-your-build-system-of-choice that wraps Cargo, so you would write make or make run to invoke cargo rustc ... or cargo build followed by your post-processing steps, possibly followed by cargo run.

However, now you have to document the custom build steps and hope users notice that instead of just running cargo build or cargo run, I don’t think this would work with cargo install, and you either have to wrap all of the cargo subcommands as well as setting up a way to pass flags through or remember which commands you need to run through make and which you can invoke with cargo directly.

So, I’m wondering if there’s anything better that I’ve missed, or I should just bite the bullet and wrap it with a Makefile?


#2

I added Rust support to Tundra for this very reason. Rust support in Tundra build system

This is mainly for building applications with and not as an extra tool “around” crates.