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:
parent
f6bd2c6de5
commit
db08ecc1bc
4 changed files with 65 additions and 7 deletions
|
|
@ -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)))
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue