rustbuild: Build jemalloc and libbacktrace only once (take 2)

[petrochenkov]

This is a rebase of #38583 without any additions, but with implemented @alexcrichton's suggestions.
This includes exists(Makefile) => cfg(stage0) suggestion... but it will break cross-compilation, no? Are libstd/liballoc_jemalloc cross-compiled for target != host built during stage0?

r? @alexcrichton

[alexcrichton]

Yeah I believe you're right in that this may break cross compiles. Perhaps !cfg!(stage0) && some_stamp_file.exists() could be checked here? That "stamp" file could be created at the end of the build.

[bors]

☔ The latest upstream changes (presumably #39252) made this pull request unmergeable. Please resolve the merge conflicts.

[petrochenkov]

!cfg!(stage0) && some_stamp_file.exists()

This is exactly what I want to avoid - redoing make's job poorly.
I've used !cfg!(stage0) && target == host - this shouldn't be a pessimization unless stage 2 is built (?).

---

The best solution is what the previous PR does - running make unconditionally (modulo rerun-if-changed) and configure if Makefile doesn't exist.
I haven't answered the argument from #38583 (comment), but it's misunderstanding. Running configure explicitly and implicitly through make are equivalent. What makes a difference (in case the build directory ended up in bad state, this certainly happens from my experience too) is purging the build directory and starting fresh build.

[alexcrichton]

Yeah target == host sounds plausible. Thinking back though I wonder if this'll break --enable-local-rebuild (or whatever the name of the flag is)? That never ends up passing --cfg stage0 but instead passes --cfg stage1 during the first build.

[petrochenkov]

I wonder if this'll break --enable-local-rebuild

Restored the solution from #38583, it's automatically correct regardless of rustbuild configuration or cross-compilation intricacies.

[alexcrichton]

@petrochenkov I've mentioned before though that this approach is empirically incorrect? For a number of reasons:

• If make regenerates the Makefile, then the build won't pick that up (even if it re-runs ./configure)
• If we change ./configure arguments, existing build directories won't pick up that change

[petrochenkov]

Ok, those are valid reasons.
I'll implement the suggestion with timestamps then.

I'll have to move libbacktrace/jemalloc builds from build scripts to bootstrap though.
Otherwise code dealing with timestamps (currently located in bootstrap/util.rs) will need to be moved to build_helper bloating it and introducing dependency on filetime crate. build_helper and its dependencies are built for all stages so it's not good.

[petrochenkov]

build_helper bloating it and introducing dependency on filetime crate. build_helper and its dependencies are built for all stages

Actually, nevermind. This is still much faster than building libbacktrace and jemalloc.
Updated the PR with timestamps.

[alexcrichton]

@bors: r+

Looks great, thanks!

[bors]

📌 Commit 0e41f13 has been approved by alexcrichton

[bors]

⌛ Testing commit 0e41f13 with merge f6ce61b...

[bors]

💔 Test failed - status-travis

[petrochenkov]

error: There are multiple `libc` packages in your project, and the specification `libc` is ambiguous.
Please re-run this command with `-p <spec>` where `<spec>` is one of the following:
  libc:0.0.0
  libc:0.2.17

Hm, is this spurious or not?

[alexcrichton]

Nah I think that's a correct error, adding a new dependency here change the dependency graph.

You can fix this though by appending :0.0.0 here

[petrochenkov]

@bors r=alexcrichton

[bors]

📌 Commit b4abb72 has been approved by alexcrichton

[bors]

⌛ Testing commit b4abb72 with merge 57ecd7a...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 57ecd7a to master...