Feedback is welcome!
7 Likes
Glad to see someone share a similar view on missing pieces and expanding the use of Rust outside the immediate Rust ecosystem. So much in fact that I had chosen the same slogan. Your proposed working groups resonate with me especially.
1 Like
and rustc should be able to dump its file-level dependency tree (like
gcc -MF->rustc --print makefile?), in a stable format, preferably a format that already exists (like Make) rather than a bespoke JSON schema.
That is --emit dep-info right? It uses a format, which I believe is make compatible. (file: depa depb)
3 Likes
Thanks. I've now updated it.
Improved support for third-party build systems in the crates themselves. In some cases, it's just a matter of coming up with standards and making pull requests against existing crates to implement them. For example, adding hooks for crates to make their system dependencies available to Meson or Bazel instead of using
build.rs.
FWIW, I recall discussions around build.rs and what features would be needed to eliminate most if not all of bespoke build.rs logic. One of those was being able to specify dependencies to wrap - my recollection is fuzzy, so I don't have any nore details. But that move would dovetail nicely with a push to nake them available to 3rd party build tools.
Edit: found the discussion I was thinking about: https://internals.rust-lang.org/t/build-rs-use-cases-and-stories-sought/9534?u=samsieber
2 Likes
It's not just that it "dovetails" with it. It's that, ideally, it would answer most of the big objections.
@kornel's big objection was that finding C libraries is hard, and all that hardness needs to be concentrated somewhere (in Rust, that hardness is the build.rs file). But if the Rust package is being built by Meson, then it should hand the responsibility for finding it over to the Meson dependency checker, and the weirdness of finding openssl is now FindOpenssl.cmake's problem. The openssl-sys package might even continue to use build.rs if you were just using standalone cargo, only employing the declarative discovery system if the project-global "stop doing fancy stuff" flag were turned on.
Yeah, if another dependency-aware build system is used, then it should be possible to "outsource" dependency search and configuration.
In the other thread there was a discussion about split of responsibility between "finding deps" build.rs and "code generating" build.rs. One special case is bindgen-using build.rs, which does both. So you can't just throw away all build.rs scripts of sys crates, you'd need a way to have two scripts and replace only the dep-searching one.
Alternatively, a build system like Bazel can sandbox the build.rs script so that it'll find the desired instance of a dependency, as it'll be the only one it can possibly find.
1 Like
Secure Code WG is the one maintaining a security advisory database. Discuss your security disclosure needs with them! Reproducible builds are also right up their alley.
There is a lot of work until we get the proper security update story in Rust. Right now the security update distribution story is nonexistent, it's impossible to check if you're even running a vulnerable version or not. I've prototyped a first step towards solving that problem, assistance in drafting an RFC for Cargo based on this would be very welcome.
4 Likes
Ah, okay then. Thanks for the info!
Speaking of security updates, I've just opened an RFC for one piece of the puzzle: https://github.com/rust-lang/rfcs/pull/2801
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.