Commit Graph
3 Commits
Author SHA1 Message Date
Chris Tate 944cae84a8 Keep an unchanged executable without selecting the runtime pack
An unchanged rebuild that kept its output still selected the runtime pack's
artifacts first, reading the stored selection, and computed the identity of
every selected artifact to open the executable cache.

- The executable cache key names the pack by its package.json text, the
  manifest's identity (its text on darwin), and the link features and
  flavor. Together they fix which artifacts the selection names.
- The cache selects the artifacts only when it needs their identities, in
  restore() and trace(). keep() checks the recorded entry, which lists them.
- A build that does not keep or restore its executable selects the pack
  before code generation, as before.
2026-10-25 00:06:13 -05:00
Chris Tate 48cbf3a89e Verify runtime pack artifacts once per file identity, and store pack selections
Every native exe build that the executable cache does not restore hashed
each selected runtime artifact before staging it, and every exe build
parsed and validated the whole runtime-pack.json manifest to select its
artifacts.

- Staging still copies each artifact. It skips the SHA-256 of an artifact
  when the file's identity (device, inode, size, mtime, ctime) is the one
  recorded the last time that path matched the same size and digest, and
  the identity does not change while the file is read. Other artifacts are
  hashed as before, and their identities are recorded after they match.
- A pack's selection for a target, compiler version, feature set, flavor
  and mode is stored, keyed by the file identities of package.json and
  runtime-pack.json. A stored selection skips parsing and validating the
  manifest; the manifest is parsed only when a caller needs it, through
  runtimePackManifest.
- The native compiler keeps both in its cache, in the runtime-pack family,
  which prune covers.
2026-10-24 09:20:05 -05:00
Chris Tate 0431240719 Reuse linked executables on Linux
The native compiler's executable cache restored a linked executable only
on darwin. On Linux every exe build linked again, even when the frontend
and object caches answered the rest of the build.

- The cache now opens on Linux when the linker is a clang driver. One link
  with `-v -Wl,-t` lists the driver's linker job and every file the linker
  loads; their identities are checked again before an entry is published
  and when it is restored.
- On Linux a key's first link only records that it was linked. A later
  link of the same key traces and publishes, so a program built once pays
  no tracing.
- The key names the runtime pack manifest by its file identity on Linux
  instead of by its text.
- The executable and object caches share one digest of the LLVM text.
- Content-addressed entries are hashed once, and identities are compared
  by field.

darwin keeps its own driver check, dry run and key.
2026-10-23 23:20:06 -05:00