rustbuild: Ensure that it's ready for distros

[alexcrichton]

Update description

To be amenable to packaging in distros, the remaining tasks for rustbuild left to be implemented are:

• Leverage Cargo workspaces
• Vendor Cargo dependencies in source tarballs, and configure the tarballs to use these dependencies

Original description

When moving to rustbuild we're going to be using Cargo as part of the build system which has historically been difficult to work with the requirements that Linux distributions have. Let's be sure that the transition process from the makefiles to rustbuild is a smooth one though and get ahead of any concerns here!

My current plan is to do the following:

• Assume that distros arrange for us to have the correct stage0 rustc binary somewhere, configured via --enable-local-rust or build.rustc in config.toml.
• Assume that distros arrange for us to have the correct stage0 cargo binary somewhere, configured similar to rustc above.
• Use the workspaces feature in Cargo to ensure that there's only one Cargo.lock for the entire rust repo, so there's one list of what we depend on as part of the build with Cargo.
• Use a vendoring solution similar to what was proposed before where our source tarballs will contain all our crates.io dependencies (e.g. gcc-rs, cmake-rs, and eventually other crates from crates.io used to build rustc).

Given all that, we will be able to build deterministically without network access, but perhaps this is not enough! I'm curious what others think about the assumptions here about rustc/cargo, or if there are other gotchas we should take care of as well.

cc @cuviper, @anguslees, @lucab, @jauhien, @fabiand

[alexcrichton]

Also for a bit of background, there's more information about what rustbuild is in this thread.

[anguslees]

Points 1-2 (providing rustc/cargo binaries) are fine now that we have build-with-previous-release.

I need to go back and read the details about the last two. Initial comments:

• It's likely we would ignore Cargo.lock and use our own specific versions of dependencies. Obviously the distro takes on the responsibility of testing the new combination in this case.
• We may need to patch rustc or some of the dependencies breaking strict content-hash approaches like the previously proposed vendoring solution. The short version is that our rustc 1.x may not actually be identical (in the cargo reproducible sense) to upstream's rustc 1.x.

[anguslees]

Oh, and cross-compiling rustc itself is a thing that would need to be supported, so we can bootstrap new architectures. I presume that's fine, just making sure it's called out explicitly.

[jirutka]

Rust and rustbuild is currently not ready for non-glibc linux distros like Alpine Linux, that is based on musl libc. The problem is that Rust doesn’t provide rustc snapshots compiled against musl (just rust-std for musl) and we cannot build rustc without rustc… It should be possible to do a cross-compilation, but that’s quite difficult and time consuming for anyone without deep knowledge of C build toolchains and Rust build process.

We’d love to make Alpine package for Rust, but without rustc snapshot for musl we’re kinda stuck. 😿

[jirutka]

elwoz wrote very good suggestions on twitter, let me copy it here:

Oddly enough, this is one of the times when you actually should read the GNU Coding Standards. Specifically, everything in section 7 (https://t.co/C2psOm27eG) is directly relevant. The most important bits are DESTDIR and all the other makefile variables that control where things get installed. Use the same set of names and the same semantics for those knobs, and that'll get you at least halfway.

[alexcrichton]

@anguslees thanks for the comments! And yeah that seems to jive well with what we discussed long ago. I wonder, would it be acceptable in the short term to vendor these small dependencies (they're mostly just part of the build system, not even the compiler) until that story is fully fleshed out? Or would we want to fully think through the Cargo.lock-and-how-it-works-in-debian story ahead of that?

Also yeah, if distros are patching specific crates, then it should be possible by patching either Cargo.toml and/or Cargo.lock, it'll just need to be explicit.

And for cross compiling, the good news is that rustbuild is far better about this than the makefiles even were! We're cross-compiling a bunch of compilers for ARM, AArch64, FreeBSD, NetBSD, etc, so it's well tested.

@jirutka I know I'd personally love to see rustc running on Alpine, I've tried it once or twice in docker and have been sad when it doesn't work! Do you know if there are cross compilers from something like Ubuntu to Alpine Linux? If we have that then the rest of the implementation should be relatively easy I believe. I believe @japaric has done work here int he past as well.

Note though that we may want to continue the discussion about Alpine in a separate issue, as unfortunately neither the makefiles nor rustbuild support it today :(. I'd want to make sure that rustbuild worked well for packaging, however, in any case!

Also thanks for the link! It turns out that make install is actually forgotten to be implemented in rustbuild, but I'll be sure to copy those details over that issue, shouldn't be too hard to implement!

[cuviper]

I generally don't want to use vendored sources for distro packaging. However, for things that are only used for the build system itself, not in any installed artifacts, it's probably ok.

[jirutka]

The same in Alpine Linux, we also don’t use vendored sources. It would be even more complicated e.g. for LLVM, because we still need some patches for LLVM to work on musl libc. And we really don’t want to maintain LLVM patches separately in multiple packages that just uses LLVM.

[anguslees]

Speaking for Debian, we're ok to vendor things that are only used in the compiler. Realistically, we might grumble a bit but it's fine to vendor anything until we start packaging other Rust-implemented applications and need to think about a more scalable maintenance process. We would prefer to continue using the system LLVM just because of source code size and build time.

I believe the Fedora rules are the strictest around this area (exceptions to no-vendoring need approval by a separate body, rather than up to maintainer's discretion) - so most likely whatever works for them will be fine for us.

[alexcrichton]

Ok, awesome, thanks for the input everyone! Sounds like this can be a placeholder bug in that case for implementing two tasks:

• Cargo workspaces
• Vendoring sources in release artifacts

I'll update the description accordingly.

[jirutka]

Before moving to rustbuild, you should definitely at least provide statically linked cargo binaries. I understand complications with rustc, but why is even cargo self-hosted, so you need prebuilt snapshot of cargo to build cargo? Sorry, but this is insane.