[wasm] Unable to use Emscripten ports not in cache

[RedMike]

Description

As part of #84356 the Emscripten cache was frozen, and a subset of the ports was included in the NuGet (limited because of NuGet package size limits?). This subset doesn't include SDL/SDL2, both of which are essential for graphical applications.

Additionally, because FROZEN_CACHE is forced on as part of the build task, there is no easy way for a project to allow local development machines to download the extra ports.

Reproduction Steps

1. Create new project using wasmbrowser template
2. Edit .csproj, and add to a <PropertyGroup>:

<WasmBuildNative>true</WasmBuildNative>
<EmccExtraLDFlags>-lSDL -s USE_SDL=2</EmccExtraLDFlags>

3. Build the project

Expected behavior

Project builds without errors.

Actual behavior

Project fails to build with the Python error (from emcc):

Exception: Attempt to lock the cache but FROZEN_CACHE is set

Regression?

No response

Known Workarounds

1. Projects can build SDL2 via Emscripten, or get the binary from the Emscripten Ports/elsewhere, and include it as a <NativeFileReference> in the csproj. This allows projects to build successfully and is simple to revert once the ports are provided via NuGet.
2. Projects can override the cache path and/or force FROZEN_CACHE to be cleared, or attempt to point at a different EMSDK install with a populated cache. This all requires an overriding target which is likely to break during workload upgrades. Example:

<Target Name="UnfreezeCache" DependsOnTargets="_PrepareForWasmBuildNative" BeforeTargets="_WasmCompileNativeFiles;_WasmCompileAssemblyBitCodeFilesForAOT;_WasmCalculateInitialHeapSize;_WasmLinkDotNet;_CheckEmccIsExpectedVersion">
    <ItemGroup>
        <EmscriptenEnvVars Remove="EM_FROZEN_CACHE=True" />
        <EmscriptenEnvVars Include="EM_FROZEN_CACHE=0" />
        <EmscriptenEnvVars Include="FROZEN_CACHE=0" />
    </ItemGroup>
</Target>

3. Developers can populate the cache locally, but this will break when workload repair is run, or if the workload upgrades.

Configuration

• .NET 8
• All WebAssembly builds
• Build issue so all browsers

Other information

I understood that the cache was frozen due to lack of guarantee of being able to write to the cache folder, and SDL ports were removed from the frozen cache because of NuGet size limits. If the size limit isn't a major concern, then re-adding SDL2 would be the simplest option. Offering MSBuild options to allow unfreezing/moving the cache is another option.

[ghost]

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

Issue Details

---

Description

As part of #84356 the Emscripten cache was frozen, and a subset of the ports was included in the NuGet (limited because of NuGet package size limits?). This subset doesn't include SDL/SDL2, both of which are essential for graphical applications.

Additionally, because FROZEN_CACHE is forced on as part of the build task, there is no easy way for a project to allow local development machines to download the extra ports.

Reproduction Steps

1. Create new project using wasmbrowser template
2. Edit .csproj, and add to a <PropertyGroup>:

<WasmBuildNative>true</WasmBuildNative>
<EmccExtraLDFlags>-lSDL -s USE_SDL=2</EmccExtraLDFlags>

3. Build the project

Expected behavior

Project builds without errors.

Actual behavior

Project fails to build with the Python error (from emcc):

Exception: Attempt to lock the cache but FROZEN_CACHE is set

Regression?

No response

Known Workarounds

1. Projects can build SDL2 via Emscripten, or get the binary from the Emscripten Ports/elsewhere, and include it as a <NativeFileReference> in the csproj. This allows projects to build successfully and is simple to revert once the ports are provided via NuGet.
2. Projects can override the cache path and/or force FROZEN_CACHE to be cleared, or attempt to point at a different EMSDK install with a populated cache. This all requires an overriding target which is likely to break during workload upgrades. Example:

<Target Name="UnfreezeCache" DependsOnTargets="_PrepareForWasmBuildNative" BeforeTargets="_WasmCompileNativeFiles;_WasmCompileAssemblyBitCodeFilesForAOT;_WasmCalculateInitialHeapSize;_WasmLinkDotNet;_CheckEmccIsExpectedVersion">
    <ItemGroup>
        <EmscriptenEnvVars Remove="EM_FROZEN_CACHE=True" />
        <EmscriptenEnvVars Include="EM_FROZEN_CACHE=0" />
        <EmscriptenEnvVars Include="FROZEN_CACHE=0" />
    </ItemGroup>
</Target>

3. Developers can populate the cache locally, but this will break when workload repair is run, or if the workload upgrades.

Configuration

• .NET 8
• All WebAssembly builds
• Build issue so all browsers

Other information

I understood that the cache was frozen due to lack of guarantee of being able to write to the cache folder, and SDL ports were removed from the frozen cache because of NuGet size limits. If the size limit isn't a major concern, then re-adding SDL2 would be the simplest option. Offering MSBuild options to allow unfreezing/moving the cache is another option.

Author:	RedMike
Assignees:	-
Labels:	arch-wasm, untriaged, area-Build-mono
Milestone:	-

[maraf]

cc @radekdoulik