How many people read build.rs files of all the transitive dependencies of a moderately large Rust project?

Autoconf is bad in this respect but it's not like the alternatives are better (maybe Bazel).

Bazel has its problems but the readability is definitely better. And bazel BUILD files are quite constrained in what it can do.

The alternatives are _better_ but still not great. build.rs is much easier to read and audit, for example, but it’s definitely still the case that people probably skim past it. I know that the Rust community has been working on things like build sandboxing and I’d expect efforts to be a lot easier there than in a mess of m4/sh where everyone is afraid to break 4 decades of prior usage.

build.rs is easier to read, but it's the tip of the iceberg when it comes to auditing.

If I were to sneak in some underhanded code, I'd do it through either a dependency that is used by build.rs (not unlike what was done for xz) or a crate purporting to implement a very useful procedural macro...

I mean, autoconf is basically a set of template programs for snffing out whether a system has X symbol available to the linker. Any replacement for it would end up morphing into it over time.

Some things are just that complex.

We have much better tools now and much simpler support matrices, though. When this stuff was created, you had more processor architectures, compilers, operating systems, etc. and they were all much worse in terms of features and compatibility. Any C codebase in the 90s was half #ifdef blocks with comments like “DGUX lies about supporting X” or “SCO implemented Y but without option Z so we use Q instead”.

That's the essence of programming in C though...

You figure out what the hardware designers actually did, and get the program written to accommodate it.