You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 

2.9 KiB

G-104 make.tcl buildsuite surface: list / info / build

Status: proposed Scope: src/make.tcl (buildsuite subcommand group), src/buildsuites/*/ (suite self-description contract: an 'info'/describe affordance per suite - suite.tcl action or manifest record), documentation (make.tcl help text, src/buildsuites README/AGENTS) Goal: an ergonomic make.tcl surface for defined buildsuite builds: 'make.tcl buildsuite list' discovers the suites under src/buildsuites (excluding _build and non-suite dirs) with one-line descriptions; 'make.tcl buildsuite info ' surfaces the configured detail for review - source records from sources.config (urls/refs/pins), the pinned zig, the product set, doc pointers; 'make.tcl buildsuite build ?args?' runs the suite's driver forwarding suite options (e.g -tclbranch, -refresh, -target when G-105 lands). Suites stay SELF-describing so copy-and-tweak trees (G-096 workflow) appear in list/info automatically without make.tcl edits. Acceptance: list shows suite_tcl90 (and any copied tree) with descriptions sourced from the suites themselves; info renders the sources.config-derived table plus zig pin and products for a named suite; build forwards arguments and streams driver output, exiting with the driver's status; the surface works when make.tcl runs under a plain tclsh and under punk kit executables; help text documents the group; the self-description contract is documented where suite authors will find it (src/buildsuites docs) and holds for a tree created by copying suite_tcl90.

Context

User requirement 2026-07-20: "an ergonomic way to run a defined buildsuite build - nice-to-have is a way to list possible builds and considering there is a fair bit of configured info for each, a way to retrieve/review info about a particular buildsuite. Presuming surface will be a subcommand or group of subcommands in make.tcl."

Design lean: make.tcl stays a THIN front - discovery by directory scan, description and info answered by the suite itself (a 'suite.tcl info' action emitting a stable record, or a small manifest the driver also reads). That keeps copied/retargeted trees first-class citizens and survives the G-102 driver-shape migration (whatever replaces suite.tcl keeps answering the same contract; make.tcl need not know which shape a suite uses).

Sibling ergonomics note: the earlier-recorded make.tcl 'vfs' wishes (build a single configured kit by name + list configured kits from mapvfs.config - noted in mapvfs.config comments and archived G-098 (achieved 2026-07-20) notes) are a separate subsystem (kit wrapping) but the same ergonomic family - a candidate to execute alongside this goal.

Relationships: G-096 (achieved 2026-07-20 - suite.tcl driver + copy-and-tweak workflow this fronts), G-102 (driver shape - the info/build contract must survive it), G-103 (family products appear in info output), G-105 (target dimension forwarded when it exists).

Notes

(none yet)