[wasm] Investigate emscripten cache usage

[pavelsavara]

Updated: now we have the cache in a separate nuget.

The cache nuget/pack will typically be installed in a non-user-writable location.

• how does this affect user builds? Command line, and VS.
• When might emcc try to write to the cache?
• Does emsdk support a "fallback" cache that could be in a user-writable location?
• TODO: Make the dotnet installation non-writeable when running Wasm.Build.Tests

Currently it's caching for both Debug/Release configurations into the same folder.

cache:INFO: generating system library: sysroot\lib\wasm32-emscripten\libc_rt_wasm.a... (this will be cached in "D:\runtime\src\mono\wasm\emsdk\upstream\emscripten\cache\sysroot\lib\wasm32-emscripten\libc_rt_wasm.a" for subsequent builds)

Questions:

• What does emcc use as keys for the cache? Can it differentiate between Debug/Release? (path? hash?)
• If it can't then what else do we need to split the cache on?

Proposed solution

Add --cache <dir> where dir is something like upstream\emscripten\cache-<configuration>\

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Currently it's caching for both configurations into the same folder.

cache:INFO: generating system library: sysroot\lib\wasm32-emscripten\libc_rt_wasm.a... (this will be cached in "D:\runtime\src\mono\wasm\emsdk\upstream\emscripten\cache\sysroot\lib\wasm32-emscripten\libc_rt_wasm.a" for subsequent builds)

Proposed solution

Add --cache <dir> where dir is something like upstream\emscripten\cache-<configuration>\

Author:	pavelsavara
Assignees:	-
Labels:	arch-wasm
Milestone:	-

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[lewing]

The cache situation needs to be fixed very soon.

[ghost]

Tagging subscribers to this area:
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Currently it's caching for both configurations into the same folder.

cache:INFO: generating system library: sysroot\lib\wasm32-emscripten\libc_rt_wasm.a... (this will be cached in "D:\runtime\src\mono\wasm\emsdk\upstream\emscripten\cache\sysroot\lib\wasm32-emscripten\libc_rt_wasm.a" for subsequent builds)

Proposed solution

Add --cache <dir> where dir is something like upstream\emscripten\cache-<configuration>\

Author:	pavelsavara
Assignees:	radekdoulik
Labels:	arch-wasm, area-VM-meta-mono
Milestone:	6.0.0

[ilonatommy]

@radekdoulik have you decided that the approach should be changed? What was the blocker?

[radekdoulik]

With on of the latest emscripten bumps we changed the way we use the cache.

We prime it before packaging the workload nuget with the cache and also when preparing docker images for CI. The cache is frozen during the user project builds as it can be located in a read-only location and it is generally good idea to not write to deployed nuget location.

There is a remaining area, where we can improve and that is the secondary (fallback) cache. I think emscripten doesn't support that, it might be good addition to the upstream.

[lewing]

cc @directhex

[lewing]

@radekdoulik please update the status here

[pavelsavara]

@radekdoulik please update the status here

please @radekdoulik