You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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>\
changed the title [-][wasm] emscripten cache should consider Debug/Release configuration[/-][+][wasm] Investigate emscripten cache usage[/+]on Oct 6, 2022
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.
Activity
lewing commentedon Jul 2, 2021
The cache situation needs to be fixed very soon.
ilonatommy commentedon Jun 16, 2022
@radekdoulik have you decided that the approach should be changed? What was the blocker?
[-][wasm] emscripten cache should consider Debug/Release configuration[/-][+][wasm] Investigate emscripten cache usage[/+]radekdoulik commentedon May 12, 2023
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 commentedon Jul 21, 2023
cc @directhex
lewing commentedon Apr 26, 2024
@radekdoulik please update the status here
pavelsavara commentedon Dec 12, 2024
please @radekdoulik