WIP: separate julia compile stages

[vtjnash]

due to recent changes / improvements to how julia handles sysimg generation, there's no longer an advantage to doing all of these operations in one step. and due to the amount of memory required for compiling .o, it could actually be a disadvantage if the host starts swapping from trying to make sys.o and sys-debug.o simultaneously.

this saves a bit of replaced code from getting put in the system image
and allows us to serialize the .o file emission while keeping
the rest of the build parallel

this isn't essential on systems with sufficient memory,
but CI is typically sufficiently constrained that this is highly beneficial

(marked WIP since I'm still investigating whether there are other tweaks that might make CI happier, etc)

[yuyichao]

and allows us to serialize the .o file emission while keeping the rest of the build parallel

Is the default build still run the *.o generation in parallel?

[vtjnash]

Is the default build still run the *.o generation in parallel?

yes. it requires calling make twice to get parallel everywhere else but not on this step

[yuyichao]

it requires calling make twice to get parallel everywhere else but not on this step

Can't this already be achieved with make julia-ui-release julia-ui-debug -jn; make -j1?

[vtjnash]

yes, but this does a bit more in parallel so it can be faster :)

[tkelman]

please keep this as discussed in the rebased-out commit

[JeffBezanson]

Agreed. Even if slightly redundant I don't see much benefit in removing this test.

[vtjnash]

we don't actually want to be installing sys.ji (which is a build intermediate). otoh, this command is now being run as part of bootstrapping, so it should be redundant to run it again as part of the tests

this test, added by e92fc78, was obsoleted by f0712f0 which removed the code path that this was supposed to test (4776757#commitcomment-9240188)

[tkelman]

Good point that we probably don't want it in the average install. So we can change this test to run in the build tree. This functionality is still valuable for anyone who wants to run from a custom image but does not have a linker available, so we should continue testing it.

[vtjnash]

This functionality is still valuable for anyone....

sadly true. this PR is actually starting to test some ideas i have for fixing that. there's no solid reason we can't emit a better incremental build. that's probably a prereq for #5155 anyhow.

[tkelman]

Also no reason we couldn't try to build and ship lld. It might not be fully functional yet in ld-mode on Windows, but link.exe mode should mostly work now AIUI.