@notriddle's Rust 2020 wishlist, or, Rust 2021: Integration

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