Replace a bunch of type-specific Wasm allocation functions with a
generic byte allocator and reusable opaque out-parameters for pointers.
This makes it a lot more ergonomic (relatively) to use the Wasm
interface and removes a dozen or so exports.
This also updates the `ghostty_type_json` `abi` field with a maximum
alignment value that host sides can use to keep every allocation aligned
properly, easily, without hardcoding numbers.
This adds a test to verify this all works as intended and runs in CI.
Replace a bunch of type-specific Wasm allocation functions with a generic
byte allocator and reusable opaque out-parameters for pointers. This
makes it a lot more ergonomic (relatively) to use the Wasm interface
and removes a dozen or so exports.
This also updates the `ghostty_type_json` `abi` field with a maximum
alignment value that host sides can use to keep every allocation aligned
properly, easily, without hardcoding numbers.
This adds a test to verify this all works as intended and runs in CI.
The ABI manifest previously had no machine-readable grammar or test that
the public export conformed to it.
Define a Draft 2020-12 schema and add a build check that executes
ghostty_type_json for native and wasm libraries before validation. Run
both forms in CI and publish the schema with the generated API docs.
This introduces a `-Dvt-features` build option for libghostty-vt that
compiles out optional feature areas, primarily so size-conscious
embedders (e.g. wasm) can significantly trim the binary.
The flag is similar to `-Dcpu`, `+feature` or `feature` to enable it,
`-feature` to disable, magic word `all` to turn all features on or off.
Example: `-Dvt-features=-all,+render-state` builds only the render state
API.
Added CI to verify the lib and tests _compile_ (we don't run it) for
each individual feature.
### Sizes
wasm32, ReleaseFast:
| Build | Bytes | Brotli |
|---|---|---|
| default (all features) | 876,500 | 218,309 |
| web interactive
(`-all,+render-state,+input-encode,+selection,+color,+grid-introspection`)
| 661,119 | 168,994 |
| read-only viewer (`-all,+render-state`) | 537,441 | 132,858 |
| bare VT core (`-all`) | 515,422 | 125,756 |
| xterm.js browser bundle (incl. renderers) | 488,663 | 99,311 |
| @xterm/headless | 182,672 | 39,651 |
Note: xterm versions are stable as of this commit.
### C Header Note
I didn't do a `vt/features.h` style header that has macros to guard
symbols for the various features. This is something we should do in the
future. The way it is now, the C header always declares everything, and
its not a problem unless an unavailable function is referenced at link
time.
This introduces a `-Dvt-features` build option for libghostty-vt that
compiles out optional feature areas, primarily so size-conscious
embedders (e.g. wasm) can significantly trim the binary.
The flag is similar to `-Dcpu`, `+feature` or `feature` to enable it,
`-feature` to disable, magic word `all` to turn all features on or off.
Example: `-Dvt-features=-all,+render-state` builds only the render
state API.
### Sizes
| Build | Bytes | Brotli |
|---|---|---|
| default (all features) | 876,500 | 218,309 |
| web interactive (`-all,+render-state,+input-encode,+selection,+color,+grid-introspection`) | 661,119 | 168,994 |
| read-only viewer (`-all,+render-state`) | 537,441 | 132,858 |
| bare VT core (`-all`) | 515,422 | 125,756 |
| xterm.js browser bundle (incl. renderers) | 488,663 | 99,311 |
| @xterm/headless | 182,672 | 39,651 |
Note: xterm versions are stable as of this commit.
This builds and publishes `ghostty-vt.wasm` binaries into our tip
GitHub releases. These are built with the proper optimization, `simd128`
CPU feature set, and run through `wasm-opt`.
This allows wasm consumers to use libghostty without a Zig toolkit.
Published two: `ghostty-vt.wasm` and `ghostty-vt-small.wasm`. The latter
is ReleaseSmall, but is 10 to 20% slower. Users choice.
Related to #10651
Default Ghostty dependency builds to libghostty-vt-only mode and
avoid initializing anything that would trigger broader dependency
requirements.
The impact of this is that Zig consumers can import ghostty-vt without
requiring Xcode on macOS.
Run the snapshot Kaitai verifier in its own required xsm job. This gives schema, fixture, checksum, and cross-record validation a distinct CI result without coupling it to the libghostty-vt test suite.
Replaces: https://github.com/ghostty-org/ghostty/pull/13427
Zig's Mach-O linker does not emit LC_ENCRYPTION_INFO_64 for physical
iOS dylibs. This allows libghostty-vt to build successfully but causes
frameworks containing it to fail App Store validation.
I think it'd be cleaner to always just build Apple targets on Apple hosts
with the native linker. We don't need to rely on Zig being correct and
this helps ensure compatibility for details like this.
Closes#12228
Supersedes #12388
**UPDATED** - Also check comments for additional details!
This commit represents the majority of the work necessary to upgrade
Ghostty to use Zig 0.16.0.
At this point, all tests pass under Linux, but more work may be
necessary to get them to build and function on other platforms.
There are some parts of this update that deserve commentary, so that
follows below:
## Expanded use of global state (IO/environment related)
Global state, once generally only used by the C library, has now been
expanded to be used across the project at large. The static local
variable that holds the state has been moved private in its source
container with all attributes that need to be accessed globally gated
behind accessors, most of which guard on testing and send test copies
instead. Use of the global state in non-testing scenarios asserts that
the state has been initialized through `init` naturally through the
optional assertion process.
The rationale for this change is to have a location to store a
general-purpose I/O implementation and environment variables, both of
which are now provided through [Juicy
Main](https://ziglang.org/download/0.16.0/release-notes.html#Juicy-Main)
and hence can no longer be accessed or mutated through stdlib without
use of lower-level system calls and hacks (some of which are employed,
but sparingly).
As the code matures, dependence on global state should naturally slim
down.
We do not allow global state to be used in libghostty-vt. There are
comptime guards that prevent this should compilation of libghostty-vt
end up pulling `global.zig`. This means that as per the last paragraph,
work has already begun to de-couple the codebase from global state where
necessary. Additionally, in some places where environment needs to be
updated and where it can be done in an isolated fashion, environment
maps are used - system-level injection of environment through the use of
`setenv` or `unsetenv` now only happens during early initialization (and
hopefully we can remove these in the future too, especially since they
require re-synchronization of the higher-level environment primitives
after this is done).
## The `lib/compat` Tree
Some stdlib features that have been removed but still either seem they
would be valuable to us or outright complex to move away from
(particularly `SegmentedList`) have been extracted from 0.15.2, updated
as needed, and placed in `src/lib/compat`. The intention again is to
allow for piecemeal migration to more modern implementations or possibly
straight local versions.
This paradigm has also allowed us to add `std.Io.Condition.waitTimeout`,
which incidentally was missed in the 0.16.0 shuffle and has been
re-added for 0.17.0. We can remove this in favor of the upstream when we
eventually migrate to that, obviously.
Note that there was a lot more of this extracted code when this work was
started, but a lot of said code has been removed (namely environment or
process/fd-related functionality).
## translate-c Issues (functional on Linux, Darwin WIP)
There have been a number of C translation issues that we have been
working through through submitted patches and the great help from folks
on the Arocc and Zig side. This is ongoing, with the remaining work to
getting things fixed mainly focused on the MacOS side. Stay tuned for
further developments.
As mentioned at the top, follow comments for more details!
