Build a complete sysroot in the cache directory

[sbc100]

Rather than adding various include paths, copy any needed headers into
the sysroot along with any libraries.

This means that emscripten can work a lot more like the
traditional cross compiler (e.g. clang -target=xxx --sysroot=yyy),
and we can start to think of the emscripten driver as a seperate
thing to the sysroot.

Fixes: #9353

[kripken]

Can you explain what the overall change is to the cache? I see reconfiguring is not needed, but I'm not sure why. In other words, what does the cache look like after this change?

[sbc100]

The reason reconfiguring if the cache is no longer necessary is that we no longer user separate cache directories for different configurations. Instead the cache directory is fixed and never changes, but the libraries being uses live in different sub-directories of the cache.

Old layout:

cache/wasm/libc.a
cache/wasm/cache.lock
cache/wasm-lto/libc.a,
cache/wasm-lto/cache.lock

New layout:

cache/cache.lock
cache/sysroot/include  (shared include dir)
cache/sysroot/lib/wasm32-emscripten/libc.a
cache/sysroot/lib/wasm32-emscripten/lto/libc.a

(not only one cache.lock exists because there is only ever one cache directory).

If you like I can take the changes relating to removing reconfigurability and separate them out and land them first? Then we could have the same layout as today but all within a single structured cache directory. Would that make it easier to review and safer to land?

[kripken]

Thanks for the explanation. Approach sgtm. The only possible downside is that before with separate cache dirs we could clear just one at a time, but I don't think we actually did that - we cleared it all. So I think this has no downsides, and only upsides.

If you like I can take the changes relating to removing reconfigurability and separate them out and land them first?

From a review point of view I'm fine either way. But that might make it safer to land, so it might be worth it.

One specific thing I worry about is our precompiled libraries support in the emsdk, which needs to be copied to the right place - I assume we'll need emsdk changes for this too?

[juj]

I believe after this change iterating work on system headers has become astronomically slower, as one needs to do emcc --clear-cache always after editing a header file, which triggers all the system libs to build.

Is there a way to get the old behavior back, or have a mode where one has fast access to iterating on system headers, which does not need either manual deployment of headers after each edit, or the process is somehow automated e.g. by checking timestamps on the source files?

[sbc100]

Yes I agree we could make it a little smoother.

I've also forgotten to run ./embuilder build sysroot --force when working on system headers. I think maybe some kind of timestamp checker that is only enabled for git developers might work.

[sbc100]

By the way, this was already true when editing source files in the system directory. The developer has to know to run ./embuilder --force <library_name> or ./emcc --clear-cache.

[sbc100]

Is knowing about ./embuilder build sysroot --force enough to make you workflow fast again for the time being?

[juj]

By the way, this was already true when editing source files in the system directory. The developer has to know to run ./embuilder --force <library_name> or ./emcc --clear-cache.

That is true. In this case I am working on WebGPU header and JS library files, where the .h files now need a embuilder build step, but looks like JS library files at least do not.

Is knowing about ./embuilder build sysroot --force enough to make you workflow fast again for the time being?

Yes, thanks, I can patch that in to my build cmdline for now.