Actually, I don't think any does. In some projects, vendored dependencies get a completely different build system, but distributions generally just prepare the environment so that the search logic finds the library.
But if all the configure.rs script shall do is produce the directives and does not actually generate files, and the output is cached by cargo, then the second level build can simply inject a known good output into the cache to bypass it.
It would be a crate. So anyone who wants to do it would maintain it. Like today.
Yes but the indirection is important for any kind of integration into larger systems. As long as dependency resolution is done in the opaque way of build.rs, rust will be problematic to use in some contexts.
Edit: sorry i missed a whole bunch of replies in this thread. Something like declaring inputs and outputs would probably be a good step in the right way.
Let’s not forget build.rs use cases which involve processing assets. For example, the most frequently used glyphs of a font could be rendered in build.rs in order to eliminate startup times of GUI applications. And for games, build.rs can potentially be used to compile and compress raw but editable assets into compact and lightweight binary data.
I don't see how making it a crate would make it any less opaque. It would be very nice if dependencies could be treated uniformly, but many of them can't and moving the complexity this creates around won't make it go away, unfortunately. Any wrapping build system will need to know about the 
dependencies anyway and because they are dependencies, it will need its own special logic around them anyway.
We already have cargo-apk and wasm-pack, because cargo is not really up to this kind of task. And I think it shouldn't try to be. Instead I would like to see integration into some already existing, general build system, that could then become the recommended tool for projects growing out of the rust-specific scope.
Such system would then also cater to needs like creating deb and rpm packages, windows installers, flatpack and oci (docker) images etc. with a rust plugin that could generate suitable defaults for it.
Speaking of packaging, that’s also related! On macOS you need build.rs scripts to behave differently if:
So same platform, 3 very different requirements for all dependencies, needing specific configuration before the build, depending on what you plan to do with the built product after the build!
It was already mentioned—and I understand most agree—that we should standardize the way C libraries and C compiler flags are specified/overridden. From there, both homebrew and bundles need a wrapping definition anyway, so that should be able to take care of setting it up.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.