Skip to content

embed-zig/esp-zig-bootstrap

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

15 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

esp-zig-bootstrap

This repository maintains version-scoped Zig bootstrap assets and scripts. Currently tracked versions:

  • 0.15.2/llvm-project
  • 0.15.2/zig-bootstrap
  • 0.15.2/patches/
  • 0.16.0/llvm-project
  • 0.16.0/zig-bootstrap
  • 0.16.0/patches/

Build

./bootstrap.sh <version> <target> <mcpu>

Example:

./bootstrap.sh 0.16.0 aarch64-macos-none baseline

Build output is written to the repository root: .out/zig-<target>-<mcpu>/

During bootstrap, patches are applied from <version>/patches/*.patch in lexical order.

Clean

./bootstrap.sh clean 0.16.0 aarch64-linux-gnu baseline
./bootstrap.sh clean 0.16.0 x86_64-macos-none baseline
  • clean only removes artifacts for the specified target:
    • <version>/.build-<target>-<mcpu>/
    • <version>/.out/zig-<target>-<mcpu>/
    • .out/zig-<target>-<mcpu>/
  • It does not delete build results for other targets.

smoke test

Run the smoke test script:

./smoke_test.sh

Regression Tests

Committed Xtensa regression cases live under each version's regression/ directory when that version has focused downstream coverage.

Run them with the current environment Zig:

./0.16.0/regression/run.sh

Or pick an explicit Zig:

ZIG=/path/to/zig ./0.16.0/regression/run.sh

See the version-specific regression README for the case list and usage details.

Release

release.sh requires a build number so all releases use v<version>-rN tags. Passing --build-number 1 produces release assets under release/v<version>-r1/ and uses artifact names such as zig-v<version>-r1-<target>-<mcpu>.tar.xz.

CI releases are tag-driven. Pushing a tag such as v0.16.0-r1 builds the matching version directory and publishes a GitHub Release with the same tag.

The workflow runs on ubuntu-24.04 and uses a target matrix, so one tag can produce multiple cross-compiled distributions. Individual target failures do not block the release; the final GitHub Release includes only successfully built artifacts.

Release notes are generated with GitHub Models through actions/ai-inference. The workflow summarizes grouped file diffs first, then asks the model to combine those summaries into final release notes. The tag must have a previous v<version>-rN tag to use as the release notes base ref. The repository or organization must also allow GitHub Models access for the selected release notes model, currently openai/gpt-4o-mini.

To refresh an existing release, delete and recreate the tag:

git tag -d v0.16.0-r1
git push origin :refs/tags/v0.16.0-r1
git tag v0.16.0-r1
git push --force origin v0.16.0-r1

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Packages

 
 
 

Contributors