If build requirements are to be standardized, I think that an amount of memory per CPU core would make more sense than an absolute amount of memory, due to the fact that current build systems (including cargo) use a process-based parallelization approach whose RAM requirements scale ~linearly with the amount of processes in flight.
The de facto standard for mid-end consumer machines (i.e. those with an Intel iSomething in it) is 2GB/core, that could be a good baseline. But if the 1GB/core that you are requesting is feasible in a straightforward way, it would be helpful for more resource-constrained environments, such as cheap cloud VMs, embedded chips, or low-end computers.
Is that optimized+debuginfo? I’ve been disabling debuginfo in 32-bit rustc builds for Fedora. Having a “bare” build is better than nothing at all…
isn’t disabled by default ? here the config.toml.example provided by 1.32.0:
# All options are commented out by default in this file, and they're commented
# out with their default values.
#optimize = true
#debug = false
#debug-assertions = false
#debuginfo = false
#debuginfo-lines = false
#debuginfo-only-std = false
#debuginfo-tools = false
I am not familiar with Fedora, could you provide a link to the patches list applied for Fedora packaging/distribution ? I would be interested to take a look (disclosure: I am the maintainer of lang/rust for OpenBSD).
Those config.toml defaults are only accurate with the default “dev” release channel. For stable/beta/nightly, you’ll still get debuginfo and debuginfo-tools = false, but debuginfo-only-std and debuginfo-lines = true. This results in -Cdebuginfo=1 just for std and its dependencies, which shouldn’t be a problem for memory usage.
For Fedora, the usual packaging policy is to build everything with optimization and debuginfo, overriding upstream defaults as needed. The rpm build will then strip those debug sections into separate files for a foo-debuginfo subpackage, so normal users don’t incur any download/storage cost for this. I believe Debian does similar.
FWIW, I think the lines setting is redundant when full debuginfo is already enabled. You could look at a verbose build log to see what -Cdebuginfo level is actually used, where 1 is just lines and 2 is full.
And in their rules:
# Work around low-memory (32-bit) architectures: https://github.com/rust-lang/rust/issues/45854
ifneq (,$(filter $(DEB_BUILD_ARCH), armhf armel mips mipsel powerpc powerpcspe))
sed -i -e '/^debuginfo-only-std = /d' "$@"
Having deleted this setting, it should take the default true for stable. The largest culprits like libsyntax_ext and librustc should be without debuginfo in this case.
However, in Debian’s latest mips log, it looks like those two crates are building at the same time. Maybe that’s still too much for the system to bear? Have you tried with ./x.py build -j1?