Rust is coming soon

[dan...@chromium.org]

Hello chromium-packagers,

As we've announced last year (https://groups.google.com/a/chromium.org/g/chromium-dev/c/0z-6VJ9ZpVU/m/BvIrbwnTAQAJ) Rust code will be part of the Chromium project soon. This will have an impact on those building and packaging Chromium.

We are close to launching a small Rust experiment on Linux. At the point where this experiment is enabled, packagers will need a Rust toolchain in order to build Chromium.

We provide a C++ toolchain in //third_party/llvm-build that can be fetched through tools/clang/scripts/update.py.

Similarly, we provide a Rust toolchain in //third_party/rust-toolchain that can be fetched through tools/rust/update_rust.py.

You do not need to use our C++ toolchain in order to use our Rust toolchain. There's no feasible alternative to using our Rust toolchain at the moment. While it is technically possible to provide your own prebuilt Rust toolchain (binaries and stdlib) through the rust_sysroot GN argument, this build configuration is not supported and is unlikely to work in the near future as we must build the Rust stdlib as part of the Chromium build in order to configure it in ways required by upstream limitations.

Thanks,

Dana

[danakj]

One more note:

If you have previously been building Clang from source to compile Chromium, with tools/clang/scripts/build.py

You can do the same if you'd like for Rust with tools/rust/build_rust.py

[Andres Salomon]

Hi,

What release can we expect to see this in? If it's enabled in beta (115) or dev (116) already, I'd like to start testing it.

Thanks,

Andres

[dan...@chromium.org]

Hello,

The current minimal rollout comes from these GN args.

enable_rust = true

enable_rust_crash = true

Those args have become true on Linux and Android as of #1153014. It looks like dev is #1156474 so you should be able to try this out on dev (116) already.

[Andres Salomon]

Thank you. Would you mind expanding a bit on the "upstream limitations" that will render a prebuilt Rust toolchain unlikely to work? For Debian, we're absolutely going to need to try using Debian's rustc packages - least of all because we support CPU architectures that the Chromium project does (and will) not.

[dan...@chromium.org]

On Fri, Jun 16, 2023 at 11:50 PM Andres Salomon <dili...@queued.net> wrote:

Thank you. Would you mind expanding a bit on the "upstream limitations" that will render a prebuilt Rust toolchain unlikely to work? For Debian, we're absolutely going to need to try using Debian's rustc packages - least of all because we support CPU architectures that the Chromium project does (and will) not.

It may be sufficient for building a Linux release, you can give it a try. In general it's not equivalent for the many build configs Chrome has to support, for instance it's not possible to specify the debug windows CRT with the prebuilt stdlib. We build our own stdlib, but the way our rules are set up, if you specify the path to the rust sysroot then the chromium build uses it instead of building its own. Secondly, we build Chrome for official with panic=abort which the stdlib needs to match. You can configure chrome to build with panic=unwind in GN instead at a cost of a bunch of binary size, or maybe you can get your rust toolchain built with panic=abort too.

[Gabriel FORTE]

Hello,

Since M117, publish_tarball has been packing the rust source tree in //third_party/rust-src (which is fine), but also keeping a full git clone of its repo in //third_party/rust-src/.git which effectively doubled the final tarball size between 116 and 117 (1.5GB to ~3GB)

If there's no specific use case to keeping the whole rust commit history in //third_party/rust-src/.git, would you mind removing it before packing the tarballs ?

Thanks,

[Dana Jansens]

On Mon, Oct 9, 2023 at 2:59 AM Gabriel FORTE <gfo...@wyplay.com> wrote:

Hello,

Since M117, publish_tarball has been packing the rust source tree in //third_party/rust-src (which is fine), but also keeping a full git clone of its repo in //third_party/rust-src/.git which effectively doubled the final tarball size between 116 and 117 (1.5GB to ~3GB)

If there's no specific use case to keeping the whole rust commit history in //third_party/rust-src/.git, would you mind removing it before packing the tarballs ?

Right, the git repo is used during the bootstrap, so it has to be there unfortunately, unless we were to replace a bunch of the upstream bootstrap steps, which would be a very large maintenance burden.

I wonder if we could make it shallow and just contain the last N commits instead.

The logic is in here https://source.chromium.org/chromium/chromium/tools/build/+/main:recipes/recipe_modules/chromium/resources/export_tarball.py;l=50-52?q=recipes%2Frecipe_modules%2Fchromium%2Fresources%2Fexport_tarball.py if you'd like to try that out.

[Robert Nagy]

On 10/10/23 10:34 -0400, Dana Jansens wrote:
> On Mon, Oct 9, 2023 at 2:59 AM Gabriel FORTE <gfo...@wyplay.com> wrote:
>
> > Hello,
> >
> > Since M117, publish_tarball has been packing the rust source tree in
> > //third_party/rust-src (which is fine), but also keeping a full git clone
> > of its repo in //third_party/rust-src/.git which effectively doubled the
> > final tarball size between 116 and 117 (1.5GB to ~3GB)
> >
> > If there's no specific use case to keeping the whole rust commit history
> > in //third_party/rust-src/.git, would you mind removing it before packing
> > the tarballs ?
> >
>
> Right, the git repo is used during the bootstrap, so it has to be there
> unfortunately, unless we were to replace a bunch of the upstream bootstrap
> steps, which would be a very large maintenance burden.

what a wonderful ecosystem ;)

[Dana Jansens]

FWIW, this is because of git submodules of C/C++ dependencies, and part of the bootstrap will initialize those submodules. The rustc build process also uses cargo, which does not require git interaction, but it's not built entirely on cargo since it relies on C/C++ dependencies and these need to be brought in via git submodules.