> Would have been much better if you could tell it the dependencies instead of having to use yet another make clone (and a bad one at that) though.

It's not intended to be used like make, with lots of shell scripts in a Makefile.

Instead, you write all the actual build code for a given task once, and package it in a Rust crate, which can then be pulled as a build-time dependency.

So, for example, there's a cmake crate (https://docs.rs/cmake/0.1.20/cmake/) that handles any project using cmake. If you just have one of two glue files written in C, you use the gcc crate (http://alexcrichton.com/gcc-rs/gcc/index.html), which—despite the name—can also handle other C compilers on other platforms. And if you need to generate code for a perfect hash function, you use phf (https://docs.rs/phf_codegen/0.7.20/phf_codegen/). And so on. If you run into some other kind of common pattern across many projects, just write and publish another crate, and call it from build.rs.

These libraries typically do a lot of work to handle things like cross-platform compatibility.

If you already assume the programmer (1) knows Rust, and (2) might be running on either Linux, MacOS or Windows, this sort of interface is much more convenient than requiring them to get Makefiles and shell scripts working, and to handle per-platform compiler invocation issues, etc.