Consumes around 13 GB of disk space. This is totally fine, and what I was expecting. Obviously it is really slow to run, so I wanted to use the incremental flag for the next changes.
It didn't complete, neither from a fresh state (after ./x.py clean) nor after building it a first time without the incremental flag. In both case it consume all my free disk space.
Also, even after building the compiler a first time up to stage 1 without the incremental flag, the second run with incremental flag took ages. It seems to not be re-using what i compiled previously.
What can I do, both in term of disk space and compilation time?
I have no knowledge about anything here, but a feeling that your observations are linked. As far as I understood your observations are:
Incremental compilation takes more disk space
Incremental compilation is not sped up by a non-incremental compilation that happened before
I would guess that non-incremental compilation can (and does) delete intermediate stuff that it doesn’t need anymore during compilation (hence needing less space) and that this stuff would be needed to speed up the following incremental re-compilation.
As hinted, just a wild guess.
Edit: This information sounds like I’m not too wrong.
Edit2: My directory after incrementally building cargo and rustdoc on stage 1 is “only” about 18GB.
Edit3: I just compiled again, now with assertions and debug on and I am getting 44.5GB size.
One thing I’m noticing is that building cargo on stage-1 seems to requiring compilation of compiler artifacts for the stage-2 compiler.
I’m not done determining how much space is saved by omitting cargo.(Edit: it saves around 11GB.) The main problem with stage-2 artifacts is that they don’t update incrementally, so compilation is always slow. I would believe there has to be a way to use a self-compiled rustc and rustdoc with an existing / older cargo. (Or you can even test your rustc and rustdoc without cargo.)
The naming of intermediate artifacts as stage-N or stage-N+1 is somewhat inconsistent; it could be that the split you're observing is just the arbitrary point where the stage cutoff is defined and displayed not matching your intuition.
Well, my intuition would’ve been that if I require compilation of cargo in ./x.py build --stage 1 src/libstd src/tools/cargo, that I get a rustc and a corresponding cargo. Also my intuition would’ve been that ./x.py build --stage 1 src/tools/cargo src/tools/rustdoc gives me rustdoc and cargo“on the same stage”.
Apparently though, --stage 1 src/tools/cargo does
Building stage0 std artifacts
Copying stage0 std from stage0
Building stage0 compiler artifacts
Copying stage0 rustc from stage0
Assembling stage1 compiler
Building stage1 std artifacts
Copying stage1 std from stage1
Building stage1 compiler artifacts
Building stage1 tool cargo
and --stage 1 src/tools/cargo does:
Building stage0 std artifacts
Copying stage0 std from stage0
Building stage0 compiler artifacts
Copying stage0 rustc from stage0
Assembling stage1 compiler
Building rustdoc for stage1
for comparison --stage 1 src/libstd does:
Building stage0 std artifacts
Copying stage0 std from stage0
Building stage0 compiler artifacts
Copying stage0 rustc from stage0
Assembling stage1 compiler
Building stage1 std artifacts
Copying stage1 std from stage1
This does seem to involve more inconsistency than just confusing naming.
Note: Everything with Building takes time, especially compiler artifacts take lots of time, and (AFAIK) everything after Assembling stage1 compiler can’t benefit from incremental compilation.
Also, some of that size is wasted on debuginfo (assuming you have debuginfo-level = 1at most, you should never set it to 2 unless you're doing something which doesn't work without it, which is really rare IME), which https://github.com/rust-lang/rust/pull/69080 fixed but it will take a while to get to beta (which is what stage0 on nightly is).