[gentoo-dev] [RFC] Dealing with default upstream Rust flags (?)

[gentoo-dev] [RFC] Dealing with default upstream Rust flags (?)

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 892 bytes --]

Hi,

Long story short, a lot of Rust upstreams are ricing in their
Cargo.toml: enabling LTO, adjusting LTO jobs to exactly 1, and even
weirder stuff.  With C, we generally have clear policies to override
this and respect user flags.  With Rust, things aren't that clear.

Say, let's look at fractal:

  [profile.release]
  debug = true
  lto = "thin"
  codegen-units = 1

Upstream is enabling LTO with 1 job (i.e. single threaded) to squeeze
as much as they can from it.  Also, they are enabling debug symbols for
some reason.  As a result, the build takes 45 minutes, if it doesn't OOM
first.

How much of that stuff should we respect?  Or should we perhaps override
it all?  Should we do some special magic via eclass, or perhaps expect
users to set specific RUSTFLAGS for that?  Perhaps set default RUSTFLAGS
in the profiles?

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: [gentoo-dev] [RFC] Dealing with default upstream Rust flags (?)

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]

On Sat, 2024-11-09 at 17:45 +0100, Michał Górny wrote:
> Hi,
> 
> Long story short, a lot of Rust upstreams are ricing in their
> Cargo.toml: enabling LTO, adjusting LTO jobs to exactly 1, and even
> weirder stuff.  With C, we generally have clear policies to override
> this and respect user flags.  With Rust, things aren't that clear.
> 
> Say, let's look at fractal:
> 
>   [profile.release]
>   debug = true
>   lto = "thin"
>   codegen-units = 1
> 
> Upstream is enabling LTO with 1 job (i.e. single threaded) to squeeze
> as much as they can from it.  Also, they are enabling debug symbols for
> some reason.  As a result, the build takes 45 minutes, if it doesn't OOM
> first.
> 
> How much of that stuff should we respect?  Or should we perhaps override
> it all?  Should we do some special magic via eclass, or perhaps expect
> users to set specific RUSTFLAGS for that?  Perhaps set default RUSTFLAGS
> in the profiles?

This stuff is unbelievably messy. Read the comments in cargo.eclass regarding
RUSTFLAGS. As things stand, user RUSTFLAGS are respected, as are some
project-specific flags but not all.

When I worked on this, I didn't look into these profile-related settings. Do
these actually have anything to do with RUSTFLAGS? I'm not sure. gyakovlev
experimented with a "gentoo" (as opposed to "release") profile a while back,
but that effort stalled.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 858 bytes --]