Web release export template fails to build when using `optimize=none`

Calinou commented 1 week ago

Tested versions

Reproducible in: 4.4.dev e65a23762b36b564eb94672031f37fdadba72333

System information

Godot v4.4.dev (e65a23762) - Fedora Linux 41 (KDE Plasma) on X11 - X11 display driver, Multi-window, 1 monitor - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4090 (nvidia; 565.57.01) - 13th Gen Intel(R) Core(TM) i9-13900K (32 threads)

Issue description

I get a build error when compiling a web export template with optimize=none. In this case, wasm-opt is not called, but I get this error:

em++: warning: -pthread + ALLOW_MEMORY_GROWTH may run non-wasm code slowly, see https://github.com/WebAssembly/design/issues/1271 [-Wpthreads-mem-growth]
Install file: "bin/godot.web.template_release.wasm32.wasm" as "bin/.web_zip/godot.wasm"
Creating 'bin/godot.web.template_release.wasm32.wrapped.js'
Install file: "bin/godot.web.template_release.wasm32.worker.js" as "bin/.web_zip/godot.worker.js"
scons: *** [bin/.web_zip/godot.worker.js] bin/godot.web.template_release.wasm32.worker.js: No such file or directory
scons: building terminated because of errors.

Using emsdk 3.1.71. For context, I use optimize=none to make builds as fast to compile as possible (even if that comes at the expense of runtime performance).

Steps to reproduce

scons -j32 platform=web target=template_release optimize=none debug_symbols=no progress=no scu_build=all

If you remove the optimize=none, the above command will build successfully.

Minimal reproduction project (MRP)

N/A

dustdfg commented 6 days ago

Ok... Does it work with 3.1.64? It highly reminded me an issue from my backlog which I even forgot to report as an issue :sweat_smile: . But it is strange that your build fails only with optimize="none" because for me and the OP from giscuss it failed even without optimize=none so maybe it is different issues

If it is the same issue, you can add to affected platforms Windows11 and Debian testing. Everything started work with 3.1.64 for me as like for OP from giscuss

Sticksman commented 4 days ago

Seems like it fails for me with or without optimize (tried reverting to 4.3 and it still failed). The .worker.js file isn't being generated at all. That being said, compiling with threads=no does work because it skips adding the worker file to the zip.

Sticksman commented 4 days ago

Doesn't work off a clean build on mac either (makes sense, we're missing a file generation step somewhere). But doesn't seem like that file has been generated since the start of 4.x

Sticksman commented 4 days ago

I decided to check the build system since it seems to pass there. The file is being brought in from the build cache. That got me curious. I downloaded the build artifact (the web_zip file) to check and found this:

// This file is no longer used by emscripten and has been created as a placeholder
// to allow build systems to transition away from depending on it.
//
// Future versions of emscripten will likely stop generating this file at all.
throw new Error('Dummy worker.js file should never be used');

I'll put together a PR to deal with this

godotengine / godot