Add R2 upload steps to the source-tarball-lib-vt job in the tip
release workflow, matching the pattern used by the xcframework
job. The tarball is uploaded to the ghostty-tip R2 bucket keyed
by commit hash, making it available at
tip.files.ghostty.org/<commit>/libghostty-vt-source.tar.gz.
Add a build-lib-vt-xcframework job to the release-tip workflow that
builds the universal xcframework with ReleaseFast, zips it, signs
it with minisign, and uploads it to both the GitHub Release and R2
blob storage. Consumers can pull the xcframework zip from the tip
release or by commit hash from tip.files.ghostty.org.
Auto-discover Swift examples via example/*/Package.swift alongside
the existing zig and cmake discovery. The new build-examples-swift
job runs on macOS, builds the xcframework with zig build -Demit-lib-vt,
then runs swift run in each example directory to verify the
xcframework links and functions correctly end-to-end.
The libghostty-vt pkg-config file was missing Libs.private, so
pkg-config --libs --static returned the same flags as the shared
case, omitting the C++ standard library needed by the SIMD code.
Additionally, the static archive did not bundle the vendored SIMD
dependencies (simdutf, highway, utfcpp), leaving consumers with
unresolved symbols when linking. If we're choosing to vendor (no -fsys)
then we should produce a fat static archive that includes them. If `-fsys`
is used, then we should not bundle them and instead reference them via
Requires.private, letting pkg-config chain to their own .pc files.
Add Libs.private with the C++ runtime (-lc++ on Darwin, -lstdc++
on Linux) and Requires.private for any SIMD deps provided via
system integration. When SIMD deps are vendored (the default),
produce a fat static archive that bundles them using libtool on
Darwin and ar on Linux. When they come from the system (-fsys=),
reference them via Requires.private instead, letting pkg-config
chain to their own .pc files.
Switch the two Windows CI jobs (build-examples-cmake-windows and
build-libghostty-vt-windows) from GitHub-hosted windows-2025 runners
to namespace-profile-ghostty-windows runners.
Add a build-dist-lib-vt job that runs distcheck with
-Demit-lib-vt=true and verifies the resulting tarball stays under
5 MB. Also downsize the build-dist runner from -md to -sm.
Add a source-tarball-lib-vt job that builds the stripped lib-vt
dist tarball and publishes it as libghostty-vt-source.tar.gz to
the tip release. Also downsize the source-tarball runner from -md
to -sm since it does not need the extra resources.
**WARNING:** We CANNOT upgrade to Xcode 26.4 with Zig 0.15 because:
https://codeberg.org/ziglang/zig/issues/31658
We have to wait and see if Zig will backport that or if we just have to
roll forward to Zig 0.16 when it comes out. At the time of this commit,
no released Zig version has the fix for that issue.
Windows tests and builds are now passing reliably. Remove the
continue-on-error safety net so failures are visible immediately.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The "Run Example" step in the build-examples-cmake-windows job
hangs, so remove it entirely. The build step is still run so
compilation is verified, but the examples are no longer executed
on Windows.
The cmake examples were failing at runtime on Windows CI for two
reasons.
The static library was installed as "libghostty-vt.a" on all
platforms, but on Windows the DLL import library is also placed in
zig-out/lib/ as "ghostty-vt.lib". The CMakeLists.txt expected the
platform-native name "ghostty-vt.lib" for the static lib, so it
picked up the tiny DLL import lib instead, silently producing a
dynamically-linked executable. That executable then failed at
runtime because the DLL was not on PATH.
Fix this by installing the static library as "ghostty-vt-static.lib"
on Windows to avoid the name collision, and updating CMakeLists.txt
to match. For the shared (DLL) example, add zig-out/bin to PATH in
the CI run step so the DLL can be found at runtime.
Add a "Run Example" step to the build-examples-cmake-windows job
so that each CMake example is executed after it is built, verifying
the resulting binaries actually work. The executable name is derived
from the matrix directory name by replacing hyphens with underscores,
matching the project convention.
On Windows, shared libraries (DLLs) require an import library (.lib)
for linking, and the DLL itself is placed in bin/ rather than lib/ by
the Zig build. The CMake wrapper was missing IMPORTED_IMPLIB on the
shared imported target, causing link failures, and assumed the shared
library was always in lib/.
Add GHOSTTY_VT_IMPLIB for the import library name, set IMPORTED_IMPLIB
on the ghostty-vt target, and fix the shared library path to use bin/
on Windows. Install the DLL and PDB to bin/ and the import library to
lib/ following standard Windows conventions. Apply the same fixes to
ghostty-vt-config.cmake.in for the find_package path.
Rename build-windows to build-libghostty-vt-windows to reflect that
it only builds and tests libghostty-vt for now, and move it next to
the other build-libghostty-vt jobs.
Replace the manual PowerShell zig download/install with mlugg/setup-zig,
which auto-detects the version from build.zig.zon and handles caching.
Upgrade the runner from windows-2022 to windows-2025. Remove the
generated-script-to-swallow-errors pattern in favor of direct zig
build commands.
Add a new CI job that runs `zig build test-lib-vt` to test the
lib-vt build step. The job mirrors the existing test job structure
with the same nix/cachix setup and skip conditions. It is also
added to the required checks list.
Remove the dedicated `zig build lib-vt` step and replace it with a
`-Demit-lib-vt` build option. This fixes two problems:
1. We can default XCFramework, app, etc. steps to false if emit-lib-vt
is true, so that the lib-vt build doesn't pull in unrelated
artifacts. **Most importantly, lib-vt alone can be build without
full Xcode installations.**
2. We can build lib-vt as part of a bundle with other artifacts if we
really want.
