Lazy dependencies are only fetched if the build script would actually
reach a usage of that dependency at runtime (when the `lazyDependency`
function is called). This can save a lot of network traffic, disk uage,
and time because we don't have to fetch and build dependencies that we
don't actually need.
Prior to this commit, Ghostty fetched almost everything for all
platforms and configurations all the time. This commit reverses that to
fetching almost nothing until it's actually needed.
There are very little downsides to doing this[1]. One downside is `zig
build --fetch` doesn't fetch lazy dependencies, but we don't rely on
this command for packaging and suggest using our custom shell script
that downloads a cached list of URLs (`build.zig.zon.txt`).
This commit doesn't cover 100% of dependencies, since some provide no
benefit to make lazy while the complexity to make them lazy is higher
(in code style typically).
Conversely, some simple dependencies are marked lazy even if they're
almost always needed if they don't introduce any real complexity to the
code, because there is very little downside to do so.
[1]: https://ziggit.dev/t/lazy-dependencies-best-dependencies/5509/5
Closes#6702
This removes our mach-glfw dependency and replaces it with an in-tree
pkg/glfw that includes both the source for compiling glfw as well as the
Zig bindings. This matches the pattern from our other packages.
This is based on the upstream mach-glfw work and therefore includes the
original license and copyright information.
The reasoning is stated in the issue but to summarize for the commit:
- mach-glfw is no longer maintained, so we have to take ownership
- mach-glfw depended on some large blobs of header files to enable
cross-compilation but this isn't something we actually care about,
so we can (and do) drop the blobs
- mach-glfw blobs were hosted on mach hosts. given mach-glfw is
unmaintained, we can't rely on this hosting
- mach-glfw relied on a "glfw" package which was owned by another
person to be Zig 0.14 compatible, but we no longer need to rely on
this
- mach-glfw builds were outdated based on latest Zig practices
As of now `gtk4-layer-shell` is unavailable on recent, stable releases
of many distros (Debian 12, Ubuntu 24.04, openSUSE Leap & Tumbleweed, etc.)
and outdated on many others (Nixpkgs 24.11/unstable, Fedora 41, etc.)
This is inconvenient for our users and severely limits where the quick
terminal can be used. As a result we then build gtk4-layer-shell ourselves
by default unless `--system` or `-fsys=gtk4-layer-shell` are specified.
This also allows me to add an idiomatic Zig API on top of the library
and avoiding adding even more raw C code in the GTK apprt.
Since we now build gtk4-layer-shell it should be theoretically available
on all Linux systems we target. As such, the `-Dgtk-layer-shell` build
option has been removed. This is somewhat of an experimental change as
I don't know if gtk4-layer-shell works perfectly across all distros, and
we can always add the option back if need be.
Related to #3224
Previously, Ghostty used a static API for async event handling: io_uring
on Linux, kqueue on macOS. This commit changes the backend to be dynamic
on Linux so that epoll will be used if io_uring isn't available, or if
the user explicitly chooses it.
This introduces a new config `async-backend` (default "auto") which can
be set by the user to change the async backend in use. This is a
best-effort setting: if the user requests io_uring but it isn't
available, Ghostty will fall back to something that is and that choice
is up to us.
Basic benchmarking both in libxev and Ghostty (vtebench) show no
noticeable performance differences introducing the dynamic API, nor
choosing epoll over io_uring.
Add a `+boo` command to show the animation from the website. The data
for the frames is compressed during the build process. This build step
was added to the SharedDeps object because it is used in both
libghostty and in binaries.
The compression is done as follows:
- All files are concatenated together using \x01 as a combining byte
- The files are compressed to a cached build file
- A zig file is written to stdout which `@embedFile`s the compressed
file and exposes it to the importer
- A new anonymous module "framedata" is added in the SharedDeps object
Any file can import framedata and access the compressed bytes via
`framedata.compressed`. In the `boo` command, we decompress the file and
split it into frames for use in the animation.
The overall addition to the binary size is 348k.
This adds a new script `update-mirror.sh` which generates the proper
blob format for R2 (or any blob storage) to mirror all of our
dependencies.
It doesn't automate updating build.zig.zon but on an ongoing basis this
should be easy to do manually, and we can strive to automate it in the
future.
I omitted iTerm2 color themes because we auto-update that via CI and
updating all of the machinery to send it to our mirror and so on is a
pain. Additionally, this doesn't mirror transitive dependencies because
Zig doesn't have a way to fetch those from a mirror instead (unless you
pre-generate a full cache like packagers but that's not practical for
day to day development).
It's hugely beneficial just to get most of our dependencies mirrored.
This fixes a regression in 1.1.1/1.1.2 where our PACKAGING docs mention
using `fetch-zig-cache.sh` but it was removed. This commit adds it back,
generating its contents from the build.zig.zon file (via zon2nix which
we use for our Nix packaging).
For packagers, there are no dependency changes: you still need Zig and
POSIX sh. For release time, Ghostty has a new dependency on `jq` but
otherwise the release process is the same. The check-zig-cache.sh script
is updated to generate the new build.zig.zon.txt file.
`zig-gobject` is a set of GObject bindings that allow us to write
GTK-facing code in Zig instead of getting hands dirty with C.
It's been tested and refined in real-life applications and several
GTK contributors agree that it is a marked improvement over using
the C API directly, such as allowing method call syntax and avoiding
many manual `@ptrCast`s.
This commit doesn't actually contain any changes to our preexisting
GTK code — the migration process is intended to begin in chunks,
firstly in self-contained components (e.g. the header bar, overlays,
etc.), and then full-scale migration can begin when we remove non-Adwaita
GTK builds for 1.2. (After all, why port code that you'll remove later
either way?)
Fixes#4554
xev.Process.wait is documented as being equivalent to calling `waitpid`,
i.e. including reaping the process. On Linux, it does this automatically
by using pidfd and the `waitid` syscall. On macOS, it wasn't doing this.
This commit updates libxev to include a fix that explicitly calls
`waitpid` for kqueue.
Multiple fixes to prevent file descriptor leaks:
- libxev eventfd now uses CLOEXEC
- linux: cgroup clone now uses CLOEXEC for the cgroup fd
- termio pipe uses pipe2 with CLOEXEC
- pty master always sets CLOEXEC because the child doesn't need it
- termio exec now closes pty slave fd after fork
There still appear to be some fd leaks happening. They seem related to
GTK, they aren't things we're accessig directly. I still want to
investigate them but this at least cleans up the major sources of fd
leakage.
Introduces static path methods and a reworked context API that makes
things generally cleaner.
This update incidentally fixed a bug we had before where the corner
triangle shade characters were drawn solid rather than medium shade.
