integrate incremental into rustbuild.py

[nikomatsakis]

I had a beautiful writeup of The Plan (tm) here but I accidentally closed the tab. D'oh. So here goes the summarized version:

• For the time being, you probably want to be doing your incremental builds with nightly, because it will have the most up to date support. Therefore, we will add a --incremental option to configure. It will imply --enable-local-rust and --enable-local-build -- meaning that instead of beta, we'll bootstrap with the local nightly. You have to manage this yourself with rustup. Stay up to date.
• --incremental will also imply a default target of stage1.
• When building the stage1 compiler, we'll supply an incremental directory.
• Furthermore, instead of building the stage2 libs with the stage1 compiler, by default we will copy them. This only works if nobody has changed the metadata format between your nightly and stage1, so we probably want a way to disable this, but it should be a big speedup most of the time.

cc @alexcrichton @michaelwoerister, sound right?

[nagisa]

Therefore, we will add a --incremental option to configure

./configure is a second-class citizen in rustbuild. Instead it should be described in terms of options on config.toml.

[alexcrichton]

Hm we've talked about this before and I think we're on the same page, but I got lost here in the terminology of stages. Perhaps you could list out the steps of how you expect the bootstrap to proceed with incremental enabled?

[nikomatsakis]

@alexcrichton here is what I imagined:

• let INCR_DIR be some place in build
• we bootstrap by running the nightly rustc with -Z incremental=$INCR_DIR
  • given that we are using --local-rust, the rustbuild logic will already switch to cfg(stage1) in such cases, sidestepping the stage0 problem
  • this generates stage0/...target.../libs
• we copy these files into stage1/lib and stage1/bin just as today
• then, if we wish to skip rebuilding libs, we additionally copy libstd and friends into stage1/...target.../libs

I think that's... it?

[alexcrichton]

Ok, sounds good to me! Effectively that's two changes to the bootstrap (at least by my terminology)

• We skip stage0 artifacts entirely. The local compiler is the stage1 compiler, and we assume that the current stage0 compiler would have generated this compiler had it been run.
• We also skip stage2 artifacts. This means that we compile the entirety of the stage1 artifacts which then become the stage2 compiler. The stage1 artifacts are assumed to then be compatible artifacts of the stage2 compiler, so we copy them over and don't actually run the stage2 compiler as part of the build.

The first step, skipping stage0, will not always work. That's the "keep your nightly up to date" problem. The second step, skipping stage2, should in theory always work. Our bots will likely assert it'll work whereas most users can just assume it works to avoid extra compiles.

[nikomatsakis]

@alexcrichton

The local compiler is the stage1 compiler, and we assume that the current stage0 compiler would have generated this compiler had it been run.

Wait, this doesn't sound quite right. I think the bootstrap compiler becomes the "local rust" (i.e., whatever is on the path). In that case, we are assuming that the current stage0 compiler is not what would have been generated but rather something very close to it, right? In particular, metadata-compatible. (I think the only place we make that assumption is if we try to copy the libs.)

[nikomatsakis]

Though reading your comment again I think we are both saying the same thing, but in different ways.

[alexcrichton]

Er yes, right. That's what we are fundamentally assuming, metadata-compatible. That's normally guaranteed of a stage1 compiler because we just built it, but because we're skipping that portion we're assuming it.

(I do think we're saying the same thing)

Bootstrapping is hard

[nikomatsakis]

@alexcrichton I suppose, more accurately, metadata and ABI compatible.