mnml-libghostty-vt-sys 0.2.3

Raw FFI bindings to Ghostty's libghostty-vt (the C API in include/ghostty/vt.h).
docs.rs failed to build mnml-libghostty-vt-sys-0.2.3
Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.

mnml-libghostty-vt-sys

Raw FFI bindings to Ghostty's libghostty-vt C ABI, generated at build time by bindgen against vendored headers under vendor/include/ (inside this crate — self-contained for crates.io consumers, no reach-up to a workspace root).

This crate exists so mnml owns its Ghostty binding surface directly against Ghostty's official C headers, rather than depending on a third-party libghostty-vt-sys on crates.io.

Linking

build.rs clones ghostty at the pinned GHOSTTY_COMMIT (kept in lock-step with the vendored headers) and runs zig build -Demit-lib-vt, then links the produced static .a. Needs zig 0.16.0 + git on PATH; the resulting .a is cached under target/ between cargo runs.

A pkg-config feature is default-on and tried first — if a libghostty-vt-static.pc shows up on PKG_CONFIG_PATH (e.g. a future prebuilt setup), that path wins and zig isn't invoked. As of 2026-08-02 no such .pc is checked in, so every host source-builds by default.

Ergonomic wrapper

Application code should depend on mnml-libghostty-vt (the safe wrapper), not this sys crate directly.

[lib].name is libghostty_vt_sys

The Cargo package is mnml-libghostty-vt-sys but the Rust [lib].name is set to libghostty_vt_sys, so use libghostty_vt_sys::… is the import path. mnml itself masks the mnml-prefixed package name via a workspace alias libghostty-vt-sys = { package = "mnml-libghostty-vt-sys", ... } in its Cargo.toml; consumers reaching for this crate directly still write use libghostty_vt_sys::….