`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.
* When using gtk as the backend, link libadwaita
* Update c.zig
* Use libadwaita's theme manager for gtk
* update the documentation for window-theme
* build: add libadwaita to the nix devshell
* forgot to properly import libadwaita
* apprt/gtk: adwaita style change
---------
Co-authored-by: Mitchell Hashimoto <mitchell.hashimoto@gmail.com>
I know not everybody uses ZLS (or LSPs in general) but I think it's very
useful and it's very handy to have it in the `flake.nix` to keep it up
to date with the `zig` version.
As with a lot of my PRs in this project, please consider the following a
disclaimer: I have 0 clue what I'm doing here and if there's a better
way to do what I'm trying to do, let me know!
