Commit Graph

12 Commits (main)

Author SHA1 Message Date
Mitchell Hashimoto fb9c52ecf4
Nuke GLFW from Orbit
This deletes the GLFW apprt from the Ghostty codebase.

The GLFW apprt was the original apprt used by Ghostty (well, before
Ghostty even had the concept of an "apprt" -- it was all just a single
application then). It let me iterate on the core terminal features,
rendering, etc. without bothering about the UI. It was a good way to get
started. But it has long since outlived its usefulness.

We've had a stable GTK apprt for Linux (and Windows via WSL) and a
native macOS app via libghostty for awhile now. The GLFW apprt only
remained within the tree for a few reasons:

  1. Primarily, it provided a faster feedback loop on macOS because
     building the macOS app historically required us to hop out of the
     zig build system and into Xcode, which is slow and cumbersome.

  2. It was a convenient way to narrow whether a bug was in the
     core Ghostty codebase or in the apprt itself. If a bug was in both
     the glfw and macOS app then it was likely in the core.

  3. It provided us a way on macOS to test OpenGL.

All of these reasons are no longer valid. Respectively:

  1. Our Zig build scripts now execute the `xcodebuild` CLI directly and
     can open the resulting app, stream logs, etc. This is the same
     experience we have on Linux. (Xcode has always been a dependency of
     building on macOS in general, so this is not cumbersome.)

  2. We have a healthy group of maintainers, many of which have access
     to both macOS and Linux, so we can quickly narrow down bugs
     regardless of the apprt.

  3. Our OpenGL renderer hasn't been compatible with macOS for some time
     now, so this is no longer a useful feature.

At this point, the GLFW apprt is just a burden. It adds complexity
across the board, and some people try to run Ghostty with it in the real
world and get confused when it doesn't work (it's always been lacking in
features and buggy compared to the other apprts).

So, it's time to say goodbye. Its bittersweet because it is a big part
of Ghostty's history, but we've grown up now and it's time to move on.
Thank you, goodbye.

(NOTE: If you are a user of the GLFW apprt, then please fork the project
prior to this commit or start a new project based on it. We've warned
against using it for a very, very long time now.)
2025-07-04 14:12:18 -07:00
Mitchell Hashimoto 201ea050bd
update PACKAGING.md to be explicit about source vs. git
Related to #7316
2025-05-09 08:27:15 -07:00
Mitchell Hashimoto f1f9db8b96
Update PACKAGING to note Zig 0.14 requirement 2025-03-13 09:18:34 -07:00
Jeffrey C. Ollie f32ad5216b build: generate a build.zig.zon.txt file for easy zig fetch scripting
This fixes a regression in 1.1.1/1.1.2 where our PACKAGING docs mention
using `fetch-zig-cache.sh` but it was removed. This commit adds it back,
generating its contents from the build.zig.zon file (via zon2nix which
we use for our Nix packaging).

For packagers, there are no dependency changes: you still need Zig and
POSIX sh. For release time, Ghostty has a new dependency on `jq` but
otherwise the release process is the same. The check-zig-cache.sh script
is updated to generate the new build.zig.zon.txt file.
2025-02-14 09:23:51 -08:00
Mitchell Hashimoto e9e82d94ac
PACKAGING: Note GLFW is not for distribution 2024-12-31 14:34:26 -08:00
Mitchell Hashimoto b3925b83ae
note source tarball name for 1.0.0 2024-12-29 13:39:11 -08:00
Mitchell Hashimoto 9c15d8de35
ci: keep old source tarballs as well 2024-12-29 13:24:28 -08:00
Mitchell Hashimoto 0abd4ea8a2
ci: release tag workflow
This adds a new workflow for building and releasing _tagged versions_
of Ghostty. The workflow is triggered automatically by new tags in the
format of `vX.Y.Z` but can also be manually triggered by running the
workflow from the GitHub Actions UI.

Release artifacts are uploaded to a completely separate R2 bucket
with its own access policy, retention, API keys, and so on.

There is currently no way to switch between "channels" in the macOS
app. I will follow up with a separate commit to add this feature.
2024-12-20 13:02:05 -08:00
Mitchell Hashimoto d205f6a560
build: -Dpie default to true in system package mode
Fixes #2673

Rather than document this too much, I think it makes sense to just
default this to true when system package mode is enabled (`--system`)
since it seems that in multiple package ecosystems this is the desired
behavior.

This can still be overridden by setting `-Dpie=false`.
2024-11-14 09:34:07 -08:00
Mitchell Hashimoto 04f752e5b8
PACKAGING: recommend -Dtarget 2024-10-30 14:34:44 -04:00
Mitchell Hashimoto 1a12355dc9
ci: add signing and tarball generation to release-tip workflow 2024-10-24 16:32:43 -07:00
Mitchell Hashimoto 92524aa2c0
PACKAGING.md 2024-10-24 14:49:19 -07:00