That said, for those of us that don't have the luxury of working only in Rust, the cargo monoculture is a problem.
Or more precisely, as a result of that monoculture there is a single implementation of build.rs and it cannot interoperate with anything else. If cargo could optionally generate a build.ninja file or some JSON with the command it runs, it would be so much easier.
This is in fact one part of the post that was based on an unironic kernel of truth. I've wrestled with this more than most people. In particular I tried to fit cargo into the Fuchsia build system, with only partial success. That approach has been abandoned and Fuchsia now translates Cargo manifests into GN build rules, which seems to be the prevailing approach for polyglot builds, especially with Bazel.
However, the experience when doing pure Rust is night and day compared with stuff like CMake. And even in a polyglot build, the Cargo manifest is a reasonably good starting point, as argued recently by matklad[1].
Obviously, build systems and package managers at large scale are very challenging to get right, otherwise we'd have a good solution by now. I personally think Bazel is a pretty good step in the right direction, but it's very clunky and awkward for smaller projects. I found Neil Mitchell's classification[2] useful. Cargo is best-in-class for the "small" and arguably "medium" cases, but starts showing its limitations beyond that. Bazel is the reverse, one of the few really workable choices for "huge" but not a great experience otherwise.
Do you have a pointer for the translation? As soon as you have a transitive dependency on libc or any other Rust binding to a C library that approach would seem to fail due to the presence of build.rs.
Yeah that's very much a special-purpose tool and cannot be used if for example the build.rs file has different output for Linux/macOS/Windows.
I like the Meson model where the meta-build system is opinionated (not as much as cargo in the case of Meson, but still quite a bit) but, at the same time, it doesn't itself take care of the build. The build is done via build.ninja, static analysis and other tools use compile_commands.json. There is no reason why cargo couldn't work this way and even preserve the same command line interface.
