Add iOS device and simulator slices to the xcframework, gated on
SDK availability via std.zig.LibCInstallation.findNative. Refactor
AppleLibs from a struct with named fields to an EnumMap keyed by
ApplePlatform so that adding new platforms only requires extending
the enum and its sdk_platforms table.
tvOS, watchOS, and visionOS are listed as not yet supported due to
Zig stdlib limitations (missing PATH_MAX, mcontext fields).
On Darwin targets, the build now automatically produces a universal
(arm64 + x86_64) XCFramework at lib/ghostty-vt.xcframework under
the install prefix. This bundles the fat static library with headers
so consumers using Xcode or Swift PM can link libghostty-vt directly.
Read the app version from a VERSION file in the build root,
trimming whitespace, and fall back to build.zig.zon if the file
is not present. This allows source tarballs to carry a VERSION
file as the source of truth for the version string.
On Windows, install as ghostty.dll + ghostty-static.lib instead of
libghostty.so + libghostty.a, following Windows naming conventions.
Guard ubsan_rt bundling in initStatic for MSVC compatibility.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
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.
Refactor GhosttyLibVt to support both shared and static library
builds via a shared initLib helper that accepts a LinkMode. The
shared and static entry points (initShared, initStatic) delegate
to this common path.
For static builds, compiler_rt and ubsan_rt are bundled to avoid
undefined symbol errors. Debug symbols (dsymutil) are skipped for
static libs since they are not linked. The install artifact uses
a "-static" suffix internally but installs as "libghostty-vt.a"
via a new installLib method. Wasm is excluded from static builds
since it has no meaningful static vs shared distinction.
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.
* ensure that `ghostty.h` compiles during basic Zig tests
* ensure that non-exhaustive enums are kept synchronized between
`ghostty.h` and their respective Zig counterpart.
* adjust some enums that varied from established conventions
- Removes unnecessary marker constant from build.zig that existed
solely to signal build root status
- Uses filesystem check (@src().file access) instead of compile-time
declaration lookup to detect when ghostty is a dependency
- Same behavior with less indirection: file resolves from build root
only when ghostty is the main project
Detect if ghostty is being built as a dependency by comparing the build
root with ghostty's source directory. When used as a dependency, skip
git detection entirely and use the version from build.zig.zon.
This fixes build failures when downstream projects have git tags that
don't match ghostty's version format. Previously, ghostty would read
the downstream project's git tags and panic at Config.zig:246 with
"tagged releases must be in vX.Y.Z format matching build.zig".
This makes `libghostty-vt` build for freestanding wasm targets (aka a
browser) and produce a `ghostty-vt.wasm` file. This exports the same C
API that libghostty-vt does.
This commit specifically makes the changes necessary for the build to
build properly and for us to run the build in CI. We don't yet actually
try using it...
- update nixpkgs now that Zig 0.15.2 is available in nixpkgs
- drop hack that worked around compile failures on systems with more
than 32 cores
- enforce patch version of Zig
Fixes various issues:
- C ABI detection was faulty, which caused some Zig programs to use
the C ABI mode and some C programs not to. Let's be explicit.
- Unit tests now tests C ABI mode.
- Build binary no longer rebuilds on any terminal change (a regression).
- Zig programs can choose to depend on the C ABI version of the terminal
lib by using the `ghostty-vt-c` module.
Related to #8924
Zig currenly has a bug where it crashes when compiling Ghostty on
systems with more than 32 cpus (See the linked issue for the gory
details). As a temporary hack, use `sched_setaffinity` on Linux systems
to limit the compile to the first 32 cores. Note that this affects the
build only. The resulting Ghostty executable is not limited in any way.
This is a more general fix than wrapping the Zig compiler with
`taskset`. First of all, it requires no action from the user or
packagers. Second, it will be easier for us to remove once the upstream
Zig bug is fixed.
This adds two explicit `zig build` steps: `run-valgrind` and
`test-valgrind` to run the Ghostty exe or tests under Valgrind,
respectively.
This simplifies the manual Valgrind calls in a few ways:
1. It automatically sets the CPU to baseline, which is a frequent and
requirement for Valgrind on newer CPUs, and generally safe.
2. It sets up the rather complicated set of flags to call Valgrind with,
importantly setting up our suppressions.
3. It enables pairing it with the typical and comfortable workflow of
specifying extra args (with `--`) or flags like `-Dtest-filter` for
tests.
GNU gettext simply is a PITA on certain platforms (i.e. Windows, musl
Linux, etc.) and currently it's not possible to cleanly remove i18n
from the build process, making building Ghostty on the aforementioned
platforms difficult. By providing users with a way to opt-out of the
i18n mechanisms (or opt-in, on platforms where i18n is disabled by
default) we can make sure that people at least have *some* way of
building Ghostty before i18n mechanisms can be integrated neatly.
Related to #7879
This commit updates `zig build test` to run Xcode tests, too. These run
in parallel to the Zig tests, so they don't add any time to the test.
The Xcode tests will _not_ run when: (1) the target is not macOS, or (2)
the `-Dtest-filter` option is non-empty. This makes it so that this
change doesn't affect non-macOS and doesn't affect the general dev cycle
because you usually will run `-Dtest-filter` when developing a core
feature.
I didn't add a step to only run Xcode tests because I find that when I'm
working in Xcode I'm probably going to run the tests from there anyways.
The integration with `zig build test` is just a convenience, especially
around CI.
Speaking of CI, this change also makes it so this will run in CI.
`zig build run` on macOS now builds the app bundle via the `xcodebuild`
CLI and runs it. The experience for running the app is now very similar
to Linux or the prior GLFW build, where the app runs, blocks the zig
command, and logs to the terminal.
`xcodebuild` has its own build cache system that we can't really hook
into so it runs on every `zig build run` command, but it does cache and
I find its actually relatively fast so I think this is a good
replacement for the glfw-based system.
This fixes an issue where stack traces were unreliable on some platforms
(namely aarch64-linux in a MacOS VM). I'm unsure if this is a bug in Zig
(defaults should be changed?) or what, because this isn't necessary on
other platforms, but this works around the issue.
I've unconditionally enabled this for all platforms, depending on build
mode (debug/test) and not the target. This is because I don't think
there is a downside for other platforms but if thats wrong we can fix
that quickly.
Some binaries have this unconditionally enabled regardless of build mode
(e.g. the Unicode tables generator) because having symbols in those
cases is always useful.
Some unrelated GTK test fix is also included here. I'm not sure why CI
didn't catch this (perhaps we only run tests for none-runtime) but all
tests pass locally and we can look into that elsewhere.
This moves the source tarball creation process into the Zig build system
and follows the autotools-standard naming conventions of `dist` and
`distcheck`.
The `dist` target creates a source tarball in the `PREFIX/dist`
directory. The tarball is named `ghostty-VERSION.tar.gz` as expected by
standard source tarball conventions.
The `distcheck` target does the same as `dist`, but also takes the
resulting tarball, extracts it, and runs tests on the extracted source
to verify the source tarball works as expected.
This commit also updates CI:
1. Tagged releases now use the new `zig build distcheck` command.
2. Tip releases now use the new `zig build dist` command.
3. A new test build tests that source tarball generation works on
every commit.
