Remove unsupported options in configure.py

[jyn514]

I've seen people using optimize = false and full-bootstrap = true in the past, without knowing
that they're not recommended. Remove optimize and a few other options that are always a bad idea,
and document that full-bootstrap is only for testing reproducible builds.

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[jyn514]

this should theoretically be supported, but it doesn't work in practice - I had a conversation a long time ago with someone trying to fix it, but can't find it. Not sure how to replicate locally, I don't have easy access to a musl machine.

[jyn514]

oh I forgot I still have access to @oli-obk's machine - I'm not sure this is actually the right error though? if anyone knows how to test this happy to try it out

/home/joshua/rustc/build/x86_64-unknown-linux-musl/stage0/bin/cargo: error while loading shared libraries: /nix/store/9rabxvqbv0vgjmydiv59wkz768b5fmbc-glibc-2.30/lib/libc.so: invalid ELF header

[Mark-Simulacrum]

I am tempted to remove support for them -- they could still be set via --set, right? It seems a little odd to have built-in support for options we don't really want to support in configure.py.

(It's probably not a good idea to remove them from config.toml{,.example}, but I'm not sure showing them in help text makes sense.)

[jyn514]

ahh right I forgot --set is a thing.

To some extent I wonder how useful it is to have separate help for configure? We have to keep it in sync with the config.toml options, which in practice means the help gets outdated quite quickly. I wonder if we should just tell people to read config.toml.example instead.

[Mark-Simulacrum]

I think the common interface for most folks not familiar with Rust (e.g., just building from source for distro/local usage) is through configure; it's never necessary but so long as we have it I think having help for the commonly used options makes sense.

The help messages for configure options are pretty basic I think; if we wanted to add a line of "these all refer to config.toml.example options; please see that for details" I'd be fine with that.

[jyn514]

I am tempted to remove support for them -- they could still be set via --set, right? It seems a little odd to have built-in support for options we don't really want to support in configure.py.

Hmm, I worry this will needlessly break people. I know at least one person (I think in debian?) running full-bootstrap on each release to make sure we don't regress reproducible builds.

I agree we should remove optimize and parallel-compiler though.

[jyn514]

Hmm. I see a lot of errors because --build is no longer supported in the configure script. I wonder if we should keep this as a way to enforce that the triple x.py detects is the same you intend to use? or maybe it's not worth keeping these around and we should just remove the --build flags?

[Mark-Simulacrum]

Hm, actually, I'm not sure we should drop --build. It's sometimes useful for CI and other environments where you could build with multiple build triples, and there's no real way for us to know which one to prefer -- for example, MSVC or mingw on Windows, or 32-bit or 64-bit Linux. I don't think there's much value in us forcing that to be set through --set.

Edit: I see the comments above about it being unsupported, but I think that isn't true? We use it on the i686-gnu CI builder (--build=i686-unknown-linux-gnu is passed to configure) and presumably that builder is running just fine...

[jyn514]

Edit: I see the comments above about it being unsupported, but I think that isn't true? We use it on the i686-gnu CI builder (--build=i686-unknown-linux-gnu is passed to configure) and presumably that builder is running just fine...

I think "unsupported" is not quite the right word - we don't support setting it to a setting other than the one x.py would autodetect. I haven't been able to replicate this unfortunately :( but I definitely remember running into weird build issues with this a while ago ...

anyway, I'll add the flag back since I can't come up with anything more definite than my memory.

[Mark-Simulacrum]

@bors r+ rollup

[bors]

📌 Commit 071f7b8 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[matthiaskrgr]

@bors r- failed in a rollup: #99023 (comment)

[jyn514]

@bors r=Mark-Simulacrum rollup=maybe

[bors]

📌 Commit 4151a5b has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[bors]

⌛ Testing commit 4151a5b with merge 2682b88...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 2682b88 to master...

[rust-timer]

Finished benchmarking commit (2682b88): comparison url.

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

• Primary benchmarks: no relevant changes found
• Secondary benchmarks: 😿 relevant regression found

	mean1	max	count2
Regressions 😿 (primary)	N/A	N/A	0
Regressions 😿 (secondary)	3.3%	3.3%	1
Improvements 🎉 (primary)	N/A	N/A	0
Improvements 🎉 (secondary)	N/A	N/A	0
All 😿🎉 (primary)	N/A	N/A	0

Cycles

Results

• Primary benchmarks: no relevant changes found
• Secondary benchmarks: 😿 relevant regressions found

	mean1	max	count2
Regressions 😿 (primary)	N/A	N/A	0
Regressions 😿 (secondary)	3.9%	4.9%	2
Improvements 🎉 (primary)	N/A	N/A	0
Improvements 🎉 (secondary)	N/A	N/A	0
All 😿🎉 (primary)	N/A	N/A	0

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

Footnotes

1. the arithmetic mean of the percent change↩↩²

2. number of relevant changes↩↩²