1adce493eb
The WASM link embeds ${MAGICDIR}/scmos (the build tree) at the VFS sys dir,
which out of source holds only the *generated* tech files. A technology's
"styles" section (styletype mos) also needs the display styles and colour
maps -- scmos ${FILES}: mos.*.dstyle / mos.*.cmap -- which are *source*
files absent from the build tree. So magic_wasm_init failed:
Couldn't open color map file "mos.7bit.std.cmap"
... minimum.tech ... [styles] ... Cannot load technology "minimum"
(In-tree this never showed because build == source. It was also masked
until now behind the wasmBinary/INCOMING_MODULE_JS_API abort.)
Embed each display file from the source tree into the same VFS dir via
$(wildcard), which matches only files that exist -- so a stale/typo'd name
in ${FILES} (e.g. the non-existent mos.7bit.mraster_dstyle) can't break the
link.
Verified on emsdk 6.0.3, both variants: smoke tests now pass 4/4 (notcl)
and 5/5 (tcl).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|---|---|---|
| .. | ||
| emscripten | ||