@ -165,13 +165,45 @@ Acceptance: from a clean checkout plus a punk-getzig-fetched pinned zig, the sui
next compile reveals). Pin-path decision put to the user: official 0.14.1 release
as-is, punkbin-hosted 0.14.0-dev.2074, or completing the 0.15.2 migration.
### 2026-07-20 increment 3: pinned zig 0.14.1 (user-chosen path) validated, hosted on punkbin, wired as suite default
- User decision: pin the first OFFICIAL release in the recipe's line - zig 0.14.1 -
rather than migrating to 0.15.x now or hosting the unreleased dev.2074. Fetched from
a ziglang community mirror (pkg.hexops.org; ziglang.org direct timed out),
minisign-verified against the zig release key (the key punk-getzig embeds), and
extracted to bin/tools/zig-x86_64-windows-0.14.1/.
- Recipe compat deltas for 0.14.1, validated to keep dev.2074 working (regression PASS
on both zigs): b.host -> b.graph.host; the redundant second UNICODE tclMain add into
tcl_objs_static removed (0.14.1 links what dev.2074's archive semantics left
unpulled); the exe's ansi tclMain copy now compiles with -UUNICODE -U_UNICODE
-DTCL_ASCII_MAIN (the zig cc driver can supply windows-default defines - under
0.14.1 the "ansi" copy came out as a duplicate UNICODE compile: lld duplicate
Tcl_MainExW/commons; upstream's TCL_ASCII_MAIN is the intended ascii-variant guard).
- Cache discipline (user insight: zig caches have needed clearing across version
changes): the driver now uses per-zig-version local caches
(.zig-cache-< version > in the staged build dir) and stages the recipe by per-item
sync instead of wholesale delete (windows can hold transient locks on cache trees).
During diagnosis both a fresh local AND isolated global cache were tested - the
0.14.1 duplicate-symbol failure was real recipe/driver behaviour, not stale cache,
but the segregation guards the class going forward.
- punkbin publish (user-directed): zig-x86_64-windows-0.14.1.zip + .minisig added to
punkbin win32-x86_64/tools with sha1sums regenerated per that repo's workflow
(NEW x2, no CHANGED), committed with provenance and PUSHED upstream (abcd87c) - the
suite pin is now fetchable from punk-getzig's primary mirror.
- suite.tcl zig resolution is now: -zig > PUNK_ZIG > pinned
bin/tools/zig-x86_64-windows-0.14.1/zig.exe > PATH; verified end-to-end with no
options (pinned default -> PASS, static+zip shells 9.0.5). README documents the pin,
the compat deltas, and the per-version cache rationale.
- The 0.15.2 migration remains parked (transformer script + findings preserved;
increment-2 record).
Remaining for acceptance:
- Pin an exact zig version retrievable via punk-getzig and have the suite consume it
(driver currently takes -zig / PUNK_ZIG / PATH; validated with 0.14.0-dev.2074;
pin path = user decision in flight). Note punk-getzig currently pins a single
$releasearchive - a per-version fetch argument (or suite-side fetch) is likely
wanted so the suite pin and the general-tools pin can differ.
- punk-getzig per-version fetch argument, so the wrapper itself can materialize the
suite's pinned 0.14.1 (currently it installs only its own single pin, 0.15.2, to
bin/tools/zig; the suite pin was materialized by the same fetch+minisign flow
manually and is hosted on punkbin). Payload growth needs the 512-byte spacer
check on re-wrap .
- Rebase the piperepl patch onto current core-9-0-branch sources; build a
piperepl-enabled variant; behaviour matrix (TCLSH_PIPEREPL unset == stock on
tty/piped/script-arg forms; =1 with a script setting ::tclsh(dorepl) 1 -> live