configure already preferred the system readline (AC_CHECK_LIB → -lreadline) and
only fell back to the bundled readline/ copy. Remove that fallback: a non-Tcl
interactive build now requires the *system* GNU readline -- both its header
(AC_CHECK_HEADER readline/readline.h, so configure fails cleanly instead of deep
in compilation) and the library -- and if neither Tcl nor readline is available
configure errors with a clear explanation of the three ways forward (build with
Tcl, install libreadline-dev, or --disable-readline).
Also drop the now-meaningless --enable-readline-bundled, and substitute
MAKE_READLINE=0 unconditionally so the Makefiles' bundled-readline path goes
inert. readline/ and all Makefiles are left untouched here (cleaned up and
removed in the following patches).
--disable-readline stays as the escape hatch: it just tells configure to ignore
the system readline and build the existing no-line-editing variant.
Verified: Tcl build rc=0 (readline off, 375 files, readline/ not built); non-Tcl
--disable-readline builds (serial); non-Tcl default with no readline dev package
now errors with the guidance message.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The generated header's path now depends on in-tree vs relocated builds
(database/database.h vs include/database/database.h), so instructions
that named it directly ("make database/database.h") are brittle.
Add a stable, path-independent top-level target:
.PHONY: prepare
prepare: ${DATABASE_H}
Being .PHONY the name is always valid, but its prerequisite is the real
file target ${DATABASE_H}, so the header is still regenerated only when
out of date -- same result, no exposed path.
Convert every "make database/database.h" in the docs, appimage
Dockerfiles, and CI workflows to "make prepare".
Verified: relocated `make prepare` generates include/database/database.h;
re-running is a no-op; touching database.h.in triggers regeneration.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Extend the Linux CI so consumers exercise more of what is buildable:
* In the Tcl job, after the default build, also build the per-module Tcl
auto-load shared libraries (lef/plot/router/ext2spice/ext2sim
tcl-main -> magiclef.so, tclplot.so, tclroute.so, exttospice.so,
exttosim.so). These are real products the default target never builds,
so building them in CI keeps them from bit-rotting.
* Add a standard_build_linux job for the non-Tcl configuration
(./configure --without-tcl): the native magic binary + bundled GNU
readline -- code paths the Tcl build does not cover, and which only
build now that the bundled-readline out-of-tree fixes landed.
NB: the standard job's apt package set is not validated on the runner;
adjust if a library is not found. Docs remain best-effort in both jobs.
Not changed here: whether the five auto-load .so should also be shipped
by the default "make install" (they currently are not) -- left as a
separate decision.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
When latex and dvips are available, the default no-arg "make" now
regenerates the PostScript documentation from its .tex sources into the
build tree; otherwise the pre-built PostScript shipped in the source tree
is used as-is at install time. Documentation is always available either
way -- installing latex simply refreshes it from source.
configure (scripts/configure.in, regenerated scripts/configure):
* AC_PATH_PROG for latex + dvips; DOCS_TARGET = "docs" only when both are
found; AC_SUBST(LATEX/DVIPS/DOCS_TARGET).
* Configuration summary prints "LaTeX docs: yes/no".
scripts/defs.mak.in: export LATEX/DVIPS.
Makefile.in:
* all: ... $(DOCS_TARGET) -- pulls in "docs" only when latex was found.
* docs: best-effort -- `make -k` + a warning on failure so a document
that will not typeset (or a missing texlive package) never fails the
build; install falls back to the pre-built PostScript for those.
doc/latexfiles/Makefile:
* use ${LATEX}/${DVIPS} from defs.mak.
* the .tex include figures as ../psfigures/*.ps; point the build-tree
../psfigures at ${MAGICSRC}/doc/psfigures (no-op in-tree) so latex and
dvips find them while outputs stay in the build tree.
CI: main.yml and main-aarch64.yml install
texlive-latex-base/-recommended + texlive-fonts-recommended so the Linux
builds exercise doc regeneration (best-effort, never fatal).
README.Tcl: document latex/dvips as an optional prerequisite for docs.
.gitignore: ignore in-tree doc build artifacts (doc/latexfiles/psfiles/,
*.dvi/*.aux/*.log); the pre-built doc/psfiles/ stays tracked.
Verified out-of-tree with TeX Live 2024: configure reports "LaTeX docs:
yes"; `make` regenerates 27/28 documents into the build tree (maint1.tex
has a genuine LaTeX error and falls back), stays exit 0; `make install`
installs the 27 regenerated PostScript from the build tree and maint1
from the source pre-built copy; the source tree is not modified.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
For tarball source: show tarball filename, download URL, and actual
SHA256 values with "(SHA matches expected value)" suffix, or
"expected SHA not known, please update workflow .yml" when no SHA is
known. The Tcl ref is omitted since it is derived and not user-supplied.
For github source: show clone URL, ref, and resolved commit-id/date.
Tarball and SHA rows are omitted as they are not relevant.
The TCL/TK BUILD INFO section in Create RELEASE-NOTES.txt is updated
with the same conditional logic using the exported env vars.
The TCL_SHA_STATUS env var is removed (replaced by per-SHA display
logic and the new TCL_TARBALL_FILENAME / TK_TARBALL_FILENAME vars).
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
CoPilot analysis
Bonus: fetch-tags workaround may be removable
The appimage workflows have this comment throughout:
#fetch-tags: true # this should work see actions/checkout~issue#1471
...and then manually run git fetch --tags as a workaround. The fetch-tags input bug referenced
in issue #1471 was fixed in a v4.x patch release. After upgrading to v7, it would be worth
testing fetch-tags: true directly and removing the manual git fetch --tags workaround in the
appimage "Create RELEASE-NOTES.txt" steps — though this is independent of the version upgrade
itself.
Previously it was an archive of an archive (of the 'npm pack' output)
published under the same artifict filename (which becomes the default
download filenmame) which is a headache when you start to download more
than one (like when testing between versions).
Now the 'npm pack' output is attached as-is using its original filename,
but also the extracted contents are attached as standard GitHub
artifact ZIP, using a unique filename (based on the unique build version).
Filter out unwanted tag version as candiates to build with:
refs/tags/core-9-0-b3 UNWANTED
refs/tags/core-9-0-b2 UNWANTED
refs/tags/core-9-0-b1-rc4 UNWANTED
refs/tags/core-9-0-b1 UNWANTED
refs/tags/core-9-0-a3 UNWANTED
refs/tags/core-9-0-a1 UNWANTED
refs/tags/core-9-0-4
refs/tags/core-9-0-3
refs/tags/core-9-0-2
refs/tags/core-9-0-1
refs/tags/core-9-0-0
Previously the lexical order would result in alpha/beta/rc
matching in preference to the stable Tcl version IDs. So our WASM
build would not be against the upstream stable release which is
the intention.
previously node20 was the default, with override to force node22 but
node24 has been out since May 2025 and is current LTS, with node26
out since May 2026 and current stable (but non-LTS).
The AppImage release workflows trigger on any tag (the project tags
releases as e.g. 8.3.662, without a v prefix), but the npm publish
gate in main-wasm.yml required a v-prefixed tag, so a normal release
tag built the AppImages but never published the npm package to GitHub
Packages. The gate now accepts both forms, so a single tag releases
everything.
Add explicit length limit to sscanf in TclmagicRegisterCommands: %92s
instead of %s prevents a potential stack overwrite if a command name
were ever longer than the buffer. Matches the available space (keyword[100]
minus the 7-byte "magic::" prefix minus null).
Extend the CI output-display step to also iterate over output-tcl/ so
that TCL-variant test regressions are visible in the job log without
downloading artifacts.
Rename *-magic.tcl scripts to *-tcl.tcl to match the -tcl.js test naming
convention. Delete the old bare-command pcell.tcl (used cellname create,
no magic:: prefix) and promote pcell-magic.tcl to pcell.tcl.
Fix misleading comment in magicWasm.c: Tclmagic_Init only bootstraps the
interpreter; magic:: commands are registered separately by
TclmagicRegisterCommands after magicMainInit. Align comment block
dashes in TclmagicRegisterCommands to match tclmagic.c style (62 dashes).
Replace intubun/tcl references in build scripts and CI with tcltk/tcl to
match the actual pinned repo in npm/tcl.ref. Also run both test suites
when build.sh is invoked with --test.
All non-TCL tests (extract, gds, drc, cif) now also run against the TCL
variant using magic::-prefixed Tcl scripts. A new PCell test generates
two parameterized rectangle cells and verifies their GDS output.
The CI workflow runs npm run test:tcl after the TCL build and saves the
generated output files as an artifact.
Bump VERSION to 8.3.645.
magic.wasm can now be built as two variants packaged in the same npm
release: notcl/ (legacy, magic's own parser) and tcl/ (intubun/tcl 9.x
statically linked, commands evaluated by Tcl_EvalEx). The TCL fork is
pinned via npm/tcl.ref and cloned/built by magic itself — the tcl/
checkout is treated as read-only and built out-of-source into
magic/build-tcl-wasm/.
Configure layer:
- New usingTk variable decoupled from usingTcl in scripts/configure.in
+ scripts/configure, so --with-tcl --without-tk is finally a valid
combination. Native Linux Tcl+Tk builds keep their previous behaviour
(both flags default to enabled).
- When usingTk is empty, configure passes -DMAGIC_NO_TK so the small
number of remaining Tk callsites in tcltk/tclmagic.{h,c} compile out,
and TKCOMMON_SRCS / USE_TK_STUBS are omitted from the link.
WASM build orchestration:
- toolchains/emscripten/build-tcl-wasm.sh builds libtcl9.x.a + libtclstub.a
+ tclConfig.sh out-of-source from a pristine intubun/tcl checkout.
- npm/build.sh grew a --variant=<tcl|notcl|both> flag and writes its
outputs into npm/tcl/ and npm/notcl/. It also clones intubun/tcl with
autocrlf=false at the SHA pinned by npm/tcl.ref.
- magic/Makefile (WASM block only): magicWasm.o is now compiled with
DFLAGS_NOSTUB so Tcl_CreateInterp resolves to libtcl9.x directly
before tclStubsPtr is set. magic.js link pulls in LIB_SPECS_NOSTUB
and -ltclstub. After rules.mak include, magic: is a phony alias for
magic.js so the generic ${MODULE} recipe doesn't fight it.
- toolchains/emscripten/defs.mak: add -sUSE_ZLIB=1 (libtcl9 references
zlib), replace -sSTACK_SIZE=N with -Wl,-z,stack-size=N (emcc >=5
rejects the setting form).
- magic/magicWasm.c bootstraps the embedded interp under MAGIC_WRAPPER
(Tcl_CreateInterp -> Tcl_Init -> Tclmagic_Init) and routes
run_command through Tcl_EvalEx.
- magic/magicTop.c: gate MagicVersion/Revision/CompileTime on
!MAGIC_WRAPPER so they don't collide with the copies in
tcltk/tclmagic.c when both objects land in the same wasm binary.
npm package:
- Subpath exports: ".", "./tcl", "./notcl". Default import keeps the
pre-existing non-TCL behaviour for backward compatibility.
- examples/smoke-tcl.mjs exercises the TCL variant.
CI:
- main-wasm.yml clones intubun/tcl at the pinned ref, builds both
variants via npm/build.sh --variant=both, runs the existing notcl
test suite and the new TCL smoke test, and publishes only on a
v<x.y.z>... git tag. Tag name (minus the leading v) becomes the
npm version.
Mirrors the AppImage versioning form (8.3.637~20260414~d157eea) as
closely as semver allows: 8.3.637-20260414.d157eea.
- package.json: placeholder 0.0.0-dev; CI always overwrites before pack
- npm-publish.yml: version step now runs unconditionally (not just on
tags), reading VERSION + git date + git hash — dry-run artifacts are
stamped too, making them unambiguously traceable to their source commit
- npm-publish.yml: target GitHub Packages instead of npm registry; no
NPM_TOKEN needed, uses GITHUB_TOKEN
- Both workflows: emsdk defaults to 'latest' on every automated run so
CI tracks emsdk HEAD and catches breakage early; version is overridable
via workflow_dispatch input
- npm-publish.yml: add parallel ARM (ubuntu-24.04-arm) WASM build job
with Emscripten diagnostics step
- main.yml, npm-publish.yml: upgrade runners from ubuntu-22.04 to
ubuntu-latest
The user-facing layer of the WASM port: a publishable npm package
plus the GitHub Actions that build and ship it.
* npm/package.json — publishes as `magic-vlsi-wasm`, ESM-only, HPND
licensed, version tracks Magic's own VERSION file (8.3.637).
Whitelists the published files and exposes index.js + index.d.ts.
* npm/index.js, npm/index.d.ts — thin JS/TS wrapper around the four
WASM exports. createMagic(opts) returns { init, runCommand,
sourceFile, update, FS } so consumers can write into the
Emscripten virtual filesystem and dispatch Magic commands from
Node.js, browsers or Web Workers.
* npm/build.sh — end-to-end build: locates emsdk (via PATH or
EMSDK_DIR), runs distclean+configure+make in the right order
(techs before mains so embed-files are present), copies
magic.js / magic.wasm into npm/. Optional --release, --test,
--pack flags. Preserves configure's exec bits across invocations.
* npm/pack.sh — produces a reproducible npm tarball by touching
every file to the build time and exporting SOURCE_DATE_EPOCH so
pacote does not rewrite mtimes to its 1985 fallback.
* npm/examples/ — runnable smoke tests for the four common
workflows (extract, gds, drc, cif), driven by examples/all.js.
Each example is self-contained and uses the bundled siliwiz
technology. helpers.js encapsulates the boilerplate.
* npm/LICENSE, npm/README.md — license text and consumer-facing
docs (install, quick-start, API, examples, build-from-source,
license, third-party content notice).
* .github/workflows/main.yml — adds a `simple_build_wasm` job that
installs a pinned emsdk (3.1.56), builds the WASM module, runs
the example test suite and uploads the npm tarball as an
artifact. Pinned for reproducibility against the post-build.sh
patches; switchable to "latest" by commenting two lines.
* .github/workflows/main-aarch64.yml — drops the now-redundant
WASM ARM job. WASM is architecture-independent.
* .github/workflows/npm-publish.yml — new workflow. Publishes to
npm on `v*` tag pushes (manual `workflow_dispatch` supported as
a dry-run). Uses the same pinned emsdk and pack.sh.
Also sets FORCE_JAVASCRIPT_ACTIONS_TO_NODE24 in both workflows to
silence the Node.js 20 deprecation warnings until
actions/upload-artifact@v6 ships a Node-24 release.
-DEMSCRIPTEN=1 appears to not be present any more by default in emcc compiler.
There is -D__EMSCRIPTEN__=1 but that would require modifying many locations
in the codebase which are already being reviewed separately under a single
source multi-platform build cleanup process.
Anyhow maybe ./configure would set -DEMSCRIPTEN=1 itself, much like -Dlinux=1
for other targets. This commits defers evaluation on that until later and just
restores how it worked before.
This task is failing due to invalid gmail email address or email outbound
MTA credentials via gmail, maybe the ${{secrets.MAILING_KEY}} is invalidated ?
While the docker image at vezzal/vezzal:v1 was last updated over 3y ago,
with vezzal/vezzal:v2 was last updated over 4y ago.
The project references a github upstream project that appears to be deleted
along with the entire user account associated with it.
https://hub.docker.com/r/vezzal/vezzalhttps://github.com/lankasaicharan/vezzal
Because this does not appear to exist this now becomes a security concern
as the docker contents can not be audited as to what it does and it runs in the
context of the main project GHA CI that produces redistributable artifacts.
If this is be reinstated maybe it should be done as .github/workflows/vezzal.yml
so an independant workflow outside of the main.yml CI workflow that is used to
quickly cross check compilation state of the project.
Darryl L. Miles
Enno Schnackenberg
Intubun