Bumps [cachix/cachix-action](https://github.com/cachix/cachix-action)
from 15 to 16.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/cachix/cachix-action/releases">cachix/cachix-action's
releases</a>.</em></p>
<blockquote>
<h2>v16</h2>
<h2>What's Changed</h2>
<ul>
<li>Add a small delay to allow post-build hooks to flush through by <a
href="https://github.com/sandydoo"><code>@sandydoo</code></a> in <a
href="https://redirect.github.com/cachix/cachix-action/pull/196">cachix/cachix-action#196</a></li>
<li>Upgraded dependencies</li>
</ul>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/cachix/cachix-action/compare/v15...v16">https://github.com/cachix/cachix-action/compare/v15...v16</a></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="0fc020193b"><code>0fc0201</code></a>
Merge pull request <a
href="https://redirect.github.com/cachix/cachix-action/issues/201">#201</a>
from cachix/bump-deps</li>
<li><a
href="9ff160dfdf"><code>9ff160d</code></a>
dist: build</li>
<li><a
href="43208f1165"><code>43208f1</code></a>
deps: pnpm update</li>
<li><a
href="177fc8ba87"><code>177fc8b</code></a>
ci: run private cache tests when secrets are available</li>
<li><a
href="9bb3a15fdb"><code>9bb3a15</code></a>
deps: devenv update</li>
<li><a
href="be5295a636"><code>be5295a</code></a>
Merge pull request <a
href="https://redirect.github.com/cachix/cachix-action/issues/197">#197</a>
from cachix/dev-restructure</li>
<li><a
href="dbbedb8579"><code>dbbedb8</code></a>
ci: split build and test scripts</li>
<li><a
href="a3f805d988"><code>a3f805d</code></a>
ci: build once with devenv</li>
<li><a
href="c48cfdb2ec"><code>c48cfdb</code></a>
ci: switch out yarn</li>
<li><a
href="9af815036c"><code>9af8150</code></a>
dist: rebuild</li>
<li>Additional commits viewable in <a
href="https://github.com/cachix/cachix-action/compare/v15...v16">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
This introduces the concept of a "dist resource" (specifically a
`GhosttyDist.Resource` type). This is a resource that may be present in
dist tarballs but not in the source tree. If the resource is present and
we're not in a Git checkout, then we use it directly instead of
generating it.
This is used for the first time in this commit for the gresource c/h
files, which depend on a variety of external tools (blueprint-compiler,
glib-compile-resources, etc.) that we do not want to require downstream
users/packagers to have and we also do not want to worry about them
having the right versions.
This also adds a check for `distcheck` to ensure our distribution
contains all the expected files.
This adds a CI test to ensure that all Zig files are properly formatted.
This avoids unrelated diff noise in future PRs.
This also runs `zig fmt` once to clean up all formatting issues for
future PRs.
I also introduced a new `xsm` (extra small) runner profile to use less
resources for our tiny tasks.
1. Refactored Nix devshell/package to make it easier to keep
LD_LIBRARY_PATH & buildInputs in sync (plus make it easier to re-use in
other Nix environment).
2. Added a CI job to ensure that Blueprints are formatted correctly and
that they will compile using `blueprint-compiler` 0.16.0.
3. Reformatted all Blueprints with `blueprint-compiler format`.
1. Refactored Nix devshell/package to make it easier to keep
LD_LIBRARY_PATH & buildInputs in sync (plus make it easier to re-use
in other Nix environment).
2. Added a CI job to ensure that Blueprints are formatted correctly and
that they will compile using `blueprint-compiler` 0.16.0.
3. Reformatted all Blueprints with `blueprint-compiler format`.
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.
Upstream is now mostly pure Zig and the build.zig.zon.* files are
generated directly by zon2nix. The JSON file is no longer used as an
intermediate file but is retained for downstream packager usage.
This allows `termio.Exec` to track processes spawned via
`FlatpakHostCommand`, finally allowing Ghostty to function as a
Flatpak.
Alongside this is a few bug fixes:
* Don't add ghostty to PATH when running in flatpak mode since it's
unreachable.
* Correctly handle exit status returned by Flatpak. Previously this was
not processed and contains extra status bits.
* Use correct type for PID returned by Flatpak.
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
`std.debug.assert(x)` _is not_ the same as `if (!x) unreachable`
because the function call is not `inline`. Since it's not inline the
Zig compiler will try to compile any code that might otherwise be
unreachable.
Also, added a CI test that compiles Ghostty in a Debian 12 container to
ensure that regressions do not happen.
This brings the internal package more in line with how the nixpkgs
package is built. It also handles recursive dependencies better than the
current system.
This now requires a separate manually triggered `publish` workflow to be
run after the release completes in order to transition the release to
the `published` state.
Practically today this only means that the release will be published to
the macOS auto-updater, but in the future we could add additional steps
such as creating a GH release or some other notifications.
Importantly, this lets us verify the release in the uploaded location
before general users are notified of the update.
