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`.
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 brings the internal package more in line with how the nixpkgs
package is built. It also handles recursive dependencies better than the
current system.
Fixes#2171
ZLS has caused us issues in our Nix shell before and I noted when we
first added it that we probably shouldn't. We now pin to release
versions of Zig so I think its reasonable to expect developers to have
ZLS installed themselves with the proper version or not use it at all.
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
Nix flake [schema] allows for a top level attribute called `nixConfig`.
This allows a flake to extend a users nix for the specific flake.
This lets us add ghostty's binary cache automatically when using the
repo (nix develop, nix build, ...).
[schema]: https://nixos.wiki/wiki/Flakes#Flake_schema
With the nixpkgs LLVM 17 PR (NixOS/nixpkgs#258614) now merged, we can
update this flake input to base off of master so that we can take
advantage of the built LLVM derivation when it's ready.
This only leaves Zig 0.12 which should mean a much reduced build time.
Note that of this writing, the derivations are still queued, so until
that happens, this update means a rebuild of LLVM 17 for anyone using
the ghostty package.
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).
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.
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!
