Embed runtime source so a self-contained joltc can build apps

`joltc build` inlines the runtime (host/chez/rt.ss and everything it loads, the
seed, compile-eval, loader, ffi, the vendored irregex) into each app binary by
reading those files off disk. That works from a jolt checkout but not from the
installed self-contained binary, which has no source tree:

  joltc build -m app.core
  => Exception in call-with-input-file: failed for host/chez/rt.ss: no such file

build-joltc now bakes the exact transitive closure of files the build inlines
into the binary as embedded resources (keyed by the path the `(load "…")` forms
use), and build.ss/dce.ss read runtime source through bld-source-string, which
takes the embedded copy when present and falls back to disk otherwise. So the
same joltc builds apps both from a checkout and standalone.

The release workflow now smoke-tests a self-contained build (compile a tiny app
from an isolated dir, run it) — this is exactly what shipped broken, so it now
gates the release. buildsmoke/shakesmoke/staticnativesmoke unchanged and green.

Build tooling only — no re-mint, no runtime change.
This commit is contained in:
Yogthos 2026-07-01 17:24:50 -04:00
parent f6bd2c6de5
commit db08ecc1bc
4 changed files with 65 additions and 7 deletions

View file

@ -90,7 +90,10 @@
;; str re-serializes the read form (compiled identically; comments/whitespace are
;; irrelevant).
(define (dce-blob-records path)
(call-with-input-file path
;; bld-source-string (build.ss) reads the embedded copy when running from a
;; self-contained joltc, else the file on disk — so tree-shake works with no
;; jolt checkout present. Forward ref: build.ss loads after this file.
(call-with-port (open-input-string (bld-source-string path))
(lambda (p)
(let loop ((acc '()))
(let ((form (read p)))