fix(ci): bust stale Homebrew glib cache on macOS runners

[tyvsmith]

Problem

macOS CI jobs (build macos-latest, test macos-latest) on multiple open PRs are failing with:

ld: warning: search path '/opt/homebrew/Cellar/glib/2.88.0/lib' not found
ld: library 'gio-2.0' not found
clang: error: linker command failed with exit code 1

Reproduces today on at least PRs #441, #445, and #448. main last ran 2026-05-19 (green, before the regression).

Cause

The workflow ran Swatinem/rust-cache@v2 before brew install gtk4 libadwaita imagemagick. When the runner had a previous cache hit, restored .rlib artifacts contained absolute paths to the Cellar version they were built against (e.g. /opt/homebrew/Cellar/glib/2.88.0). Homebrew bumped glib past 2.88.0 between 2026-05-19 and 2026-05-26; that Cellar directory no longer exists on the runner, but the cached artifacts still reference it, causing the linker failure.

Fix

Two small changes to the macOS job in .github/workflows/rust.yml:

1. Run brew install before rust-cache so current library paths are present when cargo builds against the cached artifacts.
2. Key the cache on the installed Homebrew library versions via prefix-key, so any future Homebrew bump of glib / gtk4 / libadwaita automatically invalidates the rust-cache instead of producing the same broken-path artifacts.

MACOS_LIB_VER is unset on Linux/Windows, where Swatinem/rust-cache@v2 treats an empty prefix-key as the default, so other platforms are unaffected.

Test plan

• Linux cargo build --release + cargo clippy --all-targets --release -- -D warnings pass locally with the workflow change in place
• macOS CI on this PR passes (will confirm once Actions run completes)
• PRs macos: fix Option+Arrow chords + modifier-state corruption in repeat-task cleanup #441 / macos: map Print Screen / Scroll Lock / Pause to F13/F14/F15 #445 / feat: add leave_hook symmetric to enter_hook #448 still fail until rebased onto this; they're unblocked by a rebase post-merge

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Updates the Rust CI workflow to improve cache correctness on macOS by incorporating native (Homebrew) library versions into the Rust cache key.

Changes:

• Adds a macOS-only step to record Homebrew native library versions into an environment variable.
• Reintroduces Swatinem/rust-cache@v2, now configured with a prefix-key derived from macOS library versions.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[feschber]

I'm not sure if this is a caching issue... I'm having the same issue when building locally atm

[tyvsmith]

I'm not sure if this is a caching issue... I'm having the same issue when building locally atm

Claude thinks it's still a caching issue, just happening locally too in addition to CI due to how homebrew records paths. Caveat that I didn't hit it locally.

The bad path comes from glib-sys's build script. It runs pkg-config and records cargo:rustc-link-search=/opt/homebrew/Cellar/glib//lib into target//build/glib-sys-*/output — note Homebrew's .pc files use the versioned Cellar path, not the stable /opt/homebrew/opt/glib symlink. After a brew upgrade glib, the old Cellar/glib/2.88.0 dir is deleted, but cargo reuses the cached build-script output without re-running pkg-config (the crate fingerprint hasn't changed), so the linker keeps getting -L .../glib/2.88.0/lib → library 'gio-2.0' not found.

On CI this is the restored rust-cache. Locally it's your own target/. Same mechanism. The CI log on the affected PRs confirms it: rust-cache reports full match: true, and the 2.88.0 path is used even though that run's brew install pulled current gtk4/libadwaita.

To confirm + fix locally:
pkg-config --libs-only-L gio-2.0 # shows the CURRENT, valid glib path
grep -r 2.88.0 target//build/glib-sys-/output # shows the STALE path cargo is reusing
cargo clean -p glib-sys gio-sys gobject-sys # (or full cargo clean) fixes it
If pkg-config returns a valid path, it's confirmed stale-cache rather than a broken Homebrew .pc.

[feschber]

Yeah that sounds reasonable. The fix also shouldn't break anything 👍