Repository navigation
Deprecation proposal for SCons support (emscons) #27835
Description
Tracking issue for the deprecation and removal of built-in SCons support
(emscons and tools/scons/site_scons/site_tools/emscripten).
SCons sees very little usage in the C/C++ and WebAssembly ecosystem these days,
and maintaining built-in integration in Emscripten carries ongoing maintenance
and CI overhead (such as keeping a hardcoded list of Emscripten environment
variables in sync in tools/scons and running SCons tests in CI).
Notably, the only major project using SCons with Emscripten today appears to be
the Godot Engine, and they do not use emscons or Emscripten's built-in SCons
tool (instead configuring emcc/em++/emar/emranlib directly in their own
platform/web/detect.py). A GitHub code search for emscons
and EMSCRIPTEN_TOOL_PATH similarly shows very few active projects using it.
Projects that still wish to use SCons with Emscripten can either configure
CC, CXX, AR, and RANLIB directly in their SConstruct file, or vendor
the small emscripten.py tool script directly into their own
project's site_scons/site_tools/ directory.
The process for deprecating and removing features from emscripten is laid out
in docs/process.md.
At any point in the process we may decide to delay or abort the deprecation and
close this issue.
Deprecation checklist:
- Open an issue (this)
- Send message to emscripten-discuss
- Add "deprecation" warning to
emscons/ SCons tool - Perform global search for usage in public repos
- Wait at least 4 releases or 2 months
- Remove feature from codebase
Activity
Mark SCons support (`emscons` and `tools/scons`) as deprecated (#27848)
phongn commentedon Oct 9, 2026
My company actually users SCons heavily (via the Parts overlay system) and we are preparing to use move our proof-of-concept test builds over to it. Our internal branch is significantly ahead of upstream, but we do have a backport PR open.
I've read much of emsdk's documentation before, and probably could either vendor the existing deprecated caller or more formally integrate those environment variables.
sbc100 commentedon Oct 9, 2026
Is the support you are referring too in
sconspartsactually using the upstream emscripten SCons support? I tried to figure out and it doesn't look like it is maybe? But perhaps you can confirm. If its not using out internal scons support then removing to won't effect you. This is the case for the godot engine, for example.sbc100 commentedon Oct 9, 2026
According the AI analysis non of the scons support you refer to in the sconsparts project or your PR depends on emscripten's builtin SCons support so should not be effected by this change.
sbc100 commentedon Oct 9, 2026
Global GitHub Code Search Results (AI-generated)
Global GitHub code searches across public repositories (excluding clones/forks
of Emscripten itself) for:
EMSCRIPTEN_TOOL_PATH"emscons scons"env.Tool('emscripten'EMSCONS_PKG_CONFIG_LIBDIR1. Projects Using
emscons/site_tools/emscriptenAcross all of GitHub, only a handful of distinct projects use
emsconsorEMSCRIPTEN_TOOL_PATH, and only one appears to be actively maintaining itsWebAssembly SCons build:
LordOfDragons/dragengine(93 stars) &LordOfDragons/dragonscript(9 stars) — Activeemscons sconsin.github/workflows/build_web.yml(pinnedto Emscripten
4.0.10) and callsenv.Tool('emscripten', toolpath=[os.environ['EMSCRIPTEN_TOOL_PATH']])inSConsPlatformWebWasm.py.Stellarium/stellarium-web-engine(652 stars, plus ~12forks/wrappers) — Inactive Wasm build
emscons sconsinMakefileandEMSCRIPTEN_TOOL_PATHinSConstruct. TheSConstructfile has not been updated since April 2021 and targets an older Emscripten
1.37/2.x toolchain.
webrcade/webrcade-app-fceux(4 stars, forked from the 2016gamecip/em-fceuxrepo) — Low activityemscons sconsinbuild-emscripten.shandEMSCRIPTEN_TOOL_PATHinSConstruct.veigaribo/tokiwen(0 stars, last commit Dec 2025) — Inactivepersonal project
EMSCRIPTEN_TOOL_PATHandenv.Tool('emscripten')insite_scons/platforms.py.onelife/rtt_wasm(3 stars, last commit Nov 2020) — Inactiveemscons.py sconsandEMSCRIPTEN_TOOL_PATHinSConstruct.guillaumechereau/goxel— Historical onlygoxel-0.8.0) show up in search results, but upstreamgoxelhas already removedEMSCRIPTEN_TOOL_PATHfrom itsSConstruct.2. Downstream Packaging & Tool Wrappers
Several downstream package definitions and tool wrappers list
emsconsalongsideother Emscripten entry points (
emcc,em++,emcmake,emmake, etc.) whencreating symlinks or install manifests, and will simply drop
emsconswhenupgrading:
FreeBSD ports,NetBSD pkgsrc-wip,Nixpkgs,Alpine aports,Debian, Gentoooiledmachine-overlay)zackees/clang-tool-chain3. Projects Using SCons with Emscripten Without
emsconsgodotengine/godot: Configuresemcc/em++/emar/emranlibdirectly in its own
platform/web/detect.py.sconsparts/parts(PR #18): Implements its own standaloneemsdkSCons toolchain via$EMSDKrather than usingemsconsorsite_tools/emscripten.LordOfDragons commentedon Oct 10, 2026
What is the best way forward here? I don't mind including a site_tools from emscripten if this is the recommended way to avoid build breakage.
sbc100 commentedon Oct 10, 2026
yes, perhaps if you are the last user of these tools you could just copy them into your tree? We don't have a lot of scons knowledge or expertese upstream in emscripten so that could make sense.
If more users come out the woodwork we could also delay of cancel this plan.
bdbaddog commentedon Oct 19, 2026
You can contribute that tool to scons-contrib repo?
https://github.com/SCons/scons-contrib