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
{{ message }}
Repository navigation
Re-use the emsdk build rules in emscripten-releases? #1732
Currently emscripten-releases essentially duplicates the emsdk build rules for binaryen and llvm (and emscripten itself).
This means that the emsdk build rules can bitrot (at least until @juj comes along and fixes them).
Instead, I propose that we add emsdk to the DEPS (essentially a submodule) of emscirpten-releases, and delete all the duplicated logic from emscripten-releases build.py.
I bet an AI agent could quickly identify any divergences and fix them (any such divergences already represent real issues that are probably worth fixing regardless).
The main reason that we have the logic that we do in build.py is because we use the Chromium/V8 build infrastructure for producing the builds. This includes the build machines themselves (Linux and Windows VMs, and Mac hardware), the DEPS and autoroller systems, and the toolchain and distributed build system. The latter in particular is somewhat invasive (see e.g. the reclient-related stuff in here, but since it's concerned mostly with environment variables, we might be able to separate it without too much trouble.
Another issue is just that the emsdk users might not want/need to configure the LLVM and Binaryen builds the same way we do. Part of that is toolchain and libraries; since we don't (yet) plan to move away from Chromium infrastructure for producing the builds, we need to do some custom things with the toolchain and libc++ because they aren't installed the same way vs something like a Github runner. And also emsdk users might not want to use the same options and dynamic library style that we do. (Or they may have their own requirements such as signing?). It would be interesting to find out how much overlap there is here.
A compromise could be to unify the build/packaging logic for emscripten but not LLVM and Binaryen. I think that's the place where there's likely to be more actually-shared logic.
I suppose an extension of this idea could be to have emsdk depend on emscripten directly? Right now build.py (and presumably emsdk too) invokes scripts in emscripten so at least in theory it basically depends on having some minimum version.
Activity
dschuff commentedon Jul 15, 2026
The main reason that we have the logic that we do in build.py is because we use the Chromium/V8 build infrastructure for producing the builds. This includes the build machines themselves (Linux and Windows VMs, and Mac hardware), the DEPS and autoroller systems, and the toolchain and distributed build system. The latter in particular is somewhat invasive (see e.g. the reclient-related stuff in here, but since it's concerned mostly with environment variables, we might be able to separate it without too much trouble.
Another issue is just that the emsdk users might not want/need to configure the LLVM and Binaryen builds the same way we do. Part of that is toolchain and libraries; since we don't (yet) plan to move away from Chromium infrastructure for producing the builds, we need to do some custom things with the toolchain and libc++ because they aren't installed the same way vs something like a Github runner. And also emsdk users might not want to use the same options and dynamic library style that we do. (Or they may have their own requirements such as signing?). It would be interesting to find out how much overlap there is here.
A compromise could be to unify the build/packaging logic for emscripten but not LLVM and Binaryen. I think that's the place where there's likely to be more actually-shared logic.
I suppose an extension of this idea could be to have emsdk depend on emscripten directly? Right now build.py (and presumably emsdk too) invokes scripts in emscripten so at least in theory it basically depends on having some minimum version.
sbc100 commentedon Jul 15, 2026
Regarding reclient specifically, didn't we have to disable on certain platforms? What is the current state?
dschuff commentedon Jul 15, 2026
It's currently disabled on Windows try builds but AFAIK it works for all the other builds (including windows CI builds).