Skip to content

bundle: expose the standalone AOT runtime archive#58

Merged
dank-openai merged 1 commit into
mainfrom
dank/wip/rules-xlsynth-xls-owned-runtime-aot
May 18, 2026
Merged

bundle: expose the standalone AOT runtime archive#58
dank-openai merged 1 commit into
mainfrom
dank/wip/rules-xlsynth-xls-owned-runtime-aot

Conversation

@dank-openai

@dank-openai dank-openai commented May 8, 2026

Copy link
Copy Markdown
Collaborator

Problem Solved

Consumers need a normal bundle surface for the XLS-owned standalone AOT runtime archive after it is released. They should not need to rediscover native artifact filenames or special-case local validation paths.

What Changed

  • Teach bundle materialization and download logic about the optional standalone runtime archive.
  • Export the archive through generated runtime repos and artifact config when a bundle publishes it.
  • Keep older non-AOT release bundles usable when they do not contain the new archive.
  • Add self-tests covering artifact resolution and generated runtime exports.

Validation

  • Existing rules_xlsynth self-tests passed for the updated runtime bundle surface.
  • The design was validated in downstream carrier proofs on macOS and Ubuntu 24.04 with bundles that expose the archive to real AOT consumers.

Landing Order

Depends on xlsynth/xlsynth#8. This is the bundle-contract handoff between the XLS producer artifact and downstream public and private consumers.

Stack:

⚠️ Part of a stack created by spr-multicommit. Do not merge manually using the UI - doing so may have unexpected results.

Expose the XLS-owned static runtime archive through generated runtime bundles,
while keeping older non-AOT bundle lines usable when they do not publish it.

branch:dank/wip/rules-xlsynth-xls-owned-runtime-aot
@dank-openai dank-openai force-pushed the dank/wip/rules-xlsynth-xls-owned-runtime-aot branch from f3011e4 to 1b2b4fe Compare May 13, 2026 14:59
@dank-openai dank-openai merged commit d560634 into main May 18, 2026
3 checks passed
dank-openai added a commit to xlsynth/xlsynth-crate that referenced this pull request May 19, 2026
# Problem Solved
The earlier standalone-runtime prototype proved the deployment boundary,
but it kept runtime ABI ownership in Rust by mirroring live XLS callback
objects. Runtime ABI ownership should come from XLS itself; Rust
consumers should only provide generated wrapper glue and link the
released runtime artifact.

# What Changed
- Make standalone runtime-AOT wrappers the intended generated form.
- Replace the Rust-owned shadow runtime with thin integration over the
XLS-owned standalone runtime ABI.
- Keep runtime assertions supported and reject trace-bearing artifacts
until the later trace extension lands.
- Preserve typed wrapper ergonomics while linking generated consumers
against the released static runtime archive.

# Validation
- Focused generated-wrapper and standalone-runtime tests passed on macOS
and Ubuntu 24.04.
- Final branch self-review found one constructor leak path in
`StandaloneRunner::new`; the amended head fixes it, and the follow-up
review was clean.
- Broader workspace validation reached the changed AOT suites; unrelated
local environment gaps remain recorded in the workstream (`pre-commit`
shim without a real binary on this Mac, and missing
`/opt/eda-tools/xlsynth/latest/block_to_verilog_main` for existing ECO
tests).

# Landing Order
This wave-1 consumer now follows the landed public producer handoff:
- `xlsynth/xlsynth#8` at `9f60a292e369287f2b8b7be2218dc18dddf23568`
- `xlsynth/rules_xlsynth#58` at
`d560634e4c292ecac0bc499d17173f8984d75ef5`

Final product consumers still wait for the later wave-2 producer chain
before repinning.


<!-- spr-stack:start -->
**Stack**:
-   #980
-   #971
-   #968
- ➡ #964

⚠️ *Part of a stack created by
[spr-multicommit](https://github.com/mattskl-openai/spr-multicommit). Do
not merge manually using the UI - doing so may have unexpected results.*
<!-- spr-stack:end -->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants