this should reduce the amount of rebuilds that need to occur that due to
the souce changing invalidating the cache
also note that a update to nixpkgs-stable had to occur such that the new
lib functions existed
This adds libX11 to the (wrapped) binary RUNPATH in the Nix package
fixupPhase, to ensure that the dlopen we are doing of it now in #1193
functions correctly.
Note that we patch ".ghostty-wrapped" here, as this is now the main
binary after #1104.
`wrapGAppsHook4` is recommended by nixpkgs for packaging GTK4
applications.[1] It ensures `XDG_DATA_DIRS` includes the nescessary
icons and gsettings schemas.
terminfo and shell integration files can be installed on a headless server without copying all
of Ghostty to the server. Implementation liberally cribbed from the Kitty Nix package.
This adds a nix workflow that does the following:
* Checks to see if the Zig cache fixed derivation needs its hash
updated. It does this by downloading a new cache, calculating the
hash, and comparing it against what has already been set. If the hash
is different, the workflow fails.
* Runs a Nix build if the hash is OK, testing the build of
packages.ghostty (using "nix build .")
The cache workflow we use in the build job comes from:
https://github.com/DeterminateSystems/magic-nix-cache-action/Fixes#937.
This updates the zigCacheHash and just adds a note mentioning that using
the package will require you to rebuild LLVM 17 and Zig, and directs
people to use the devShell until this is resolved.
This is likely good advice for most people until such time that both are
in nixpkgs (or at least LLVM 17 as it's by far the bigger culprit here).
I figured out how to override the hook default build flags so that we
can set -Doptimize=ReleaseFast. :)
There's a long conversation that's gone on about this in nixpkgs, but
it's fairly well summed up here:
https://github.com/ziglang/zig/issues/14281#issuecomment-1624220653
I'd imagine we will want to adopt whatever is eventually done - after
this, we can remove the override and rely on more first-class
configuration, or logic in build.zig.
This fixes the Nix *package* build (read: not devShell, which is not
touched) so that it builds, and also conforms to what is generally seen
for a Zig project in nixpkgs.
The highlights:
* We use a Zig 0.12 derivation that I constructed from the Zig 0.11
derivation, in addition to LLVM 17 updates found in
NixOS/nixpkgs#258614. This specifically includes the patches that
address ziglang/zig#15898, and also allows us to take advantage of the
build hooks included in the Zig toolchain there.
* We pre-download the cache using "zig build --fetch" and a fixed-output
derivation. This is similar to how the Go builders work in nixpkgs and
I could see Zig ultimately going in a similar path, given that the
fetcher part of the build system seems to be shaping up to having a Go
module system-style DX (mind you, this is a naive opinion right now).
* Finally, cleaned up the derivation so that there's no special fixups
happening outside of what is defined in the basic nixpkgs workflow.
This is similar to other Zig projects I looked at (notably River) that
seem to just include their dependencies in buildInputs and call it a
day.
One specific change that is worth noting is that this changes the build
mode from ReleaseFast to ReleaseSafe - this is the current default
within the Zig build hook in nixpkgs. If we need ReleaseFast, we'll have
to override this.
