Use separate sysroot directories for check and build

[jyn514]

This allows running both in parallel, I think. I don't know how to test this; I tried running x.py check and x.py build at the same time but it seems to be non-deterministic whether that causes an error.

Hopefully fixes #76661.

r? @Mark-Simulacrum

[spastorino]

👍 but, what happens if you run check twice or build twice?. Maybe a solution like this one is a pragmatic enough one anyway?.

[jyn514]

Cargo will block like normal:

Checking std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Blocking waiting for file lock on build directory

The reason this broke before is it wasn't using cargo's locking: it would be building the standard library and rustc at the same time, which was two separate cargo invocations. Now that it's using different sysroots, cargo knows about all the compiles going on, so it can lock correctly.

[Mark-Simulacrum]

Seems okay, even though I'm not a fan of the solution proposed here (e.g., I would expect we still run into trouble with doc vs. build or other combinations). Maybe we should just do what cargo does except globally (i.e., a global flock file)?

Either solution seems a bit unfortunate...

cc @alexcrichton as well since I imagine you might have thoughts on this (having dealt with locking in Cargo more than I)

[alexcrichton]

I don't think I'd bother solving the original issue. Most build systems aren't design to be run in parallel, and rustbuild definitely isn't either. This seems like a pretty big hammer for a pretty niche problem.

[jyn514]

This seems like a pretty big hammer for a pretty niche problem.

I don't think I'd describe this as niche. I run into this frequently enough that I've stopped recommending rust-analyzer for rustc itself, because it runs check in the background and messes up your actual build. That said, I'm not attached to this particular solution - do you have a 'smaller hammer' in mind?

[jyn514]

cc @RalfJung

[alexcrichton]

Sorry I don't know what a less invasive solution would look like.

[Mark-Simulacrum]

I think the least invasive and maybe quite simple solution is to create a file in the root of the build directory when rustbuild starts up and delete it on any exit (maybe in Python would be best); if the file exists we can wait on it's deletion (probably just check every second or something, not sure if there's a better way). It's not great but should work ok and solves this problem for all of rustbuild.

[Mark-Simulacrum]

@jyn514 to check in, do you think you'd be interested in implementing the solution I suggested above?

[jyn514]

@Mark-Simulacrum yes, I just haven't gotten around to it.

[jyn514]

I'm probably not going to get to this any time soon. Since the current approach is too big a hammer, I'll close this and someone can pick up the solution Mark proposed in #77779 (comment) if they like.