Cachix doesn't have rate limit issues like GitHub Actions does and I'd
love to support the Nix community. Plus, I have experience with Cachix
before and they've been so great.
This adds more metadata back into the Info.plist for a build. This
metadata is used with the About window. The reason I want the build
number back is so that we have a monotonically increasing number to do
self-updating with (i.e. Sparkle).
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.
Using the "build number" (i.e. the commit number) did not seem to work
correctly anyway (it always showed '1' for releases built in CI).
Presumably this is because GitHub performs a shallow clone so it does
not have full access to the Git history.
Instead of the build number, use the Git commit hash of HEAD, which
works even for shallow clones and is more useful for debugging.
Flatpak support has been a HUGE pain to keep working, the builds take
forever and cost me real money, and there are very few users. Ideally,
we want to just use native system packagers for each distro. I thought
Flatpak would make it easy to support many distros but that ended up
being false.
The GLFW build has grown farther and farther in feature parity with GTK
on Linux. And on macOS, the GLFW build has been unstable (crashes) for
months.
I still find the GLFW build useful for testing some core terminal work,
but it is increasingly user-hostile in case someone just downloads the
project and does a `zig build`.
I keep GLFW as up to date as I can, but the features that are missing
are due to fundamental limitations:
- GLFW has no tabs, splits, etc. because it has no UI elements.
I am not interested in painting UI widgets from scratch.
- GLFW cannot support keyboard layouts robustly because it has no
hooks to detect keyboard layouts or functions to get keymaps.
- GLFW cannot support the Kitty keyboard protocol because the
key/char API is too high level and it provides no low-level
alternatives.
- GLFW crashes on macOS under certain scenarios (this is my problem).
I'm not interested in fixing it because the AppKit-based build
is highly recommended.
To build or run the GLFW build you must now explicitly pass in
`-Dapp-runtime=glfw` to `zig build`.
This should fix#158. Instead of manually copying the resources, we
create a relative dependency from the xcodeproj directly so that
xcodebuild should handle this for us.
