mirror of
https://github.com/logos-co/nix-bundle-macos-app.git
synced 2026-08-27 09:11:10 +00:00
Dario LipicarandCursor
140f4ec32e
* chore: bump nix-bundle-dir to main (cb9afc8)
Two revisions behind: 0dc73e8ec -> cb9afc8. The headline work in that range
is Linux-only (the ld.so trampoline is gone, every bundled ELF now gets the
interpreter its psABI mandates, DT_RPATH replaces DT_RUNPATH, the
LD_PRELOAD /proc/self/exe shim is deleted, and the launcher is emitted only
when a bundle needs an env var its libraries cannot derive), so the
expectation was that this bump is a no-op here.
It is not quite. c88566a ("fix rpaths") gives every Mach-O a bare
@loader_path LC_RPATH in addition to @loader_path/../lib, so a plugin staged
outside Contents/Frameworks can find the companion dylibs sitting next to
it. That is the only difference in the .app built from a plain subject:
same file list, one extra load command, hence new signatures. 061a9a8 and
adea897 can add payload too (Contents/libexec/QtWebEngineProcess,
resources/, translations/ for QtWebEngine apps; share/X11/xkb where
libxkbcommon is bundled), though neither is reachable from a non-Qt subject.
The new guiApp knob is Linux-only, and the qtCliApp bundler it adds is
mirrored here automatically by the bundlers map.
* ci: assert the .app contract on a macOS runner
This repo produces the artifact a user double-clicks and had no automated
gate at all. Its failure modes are the ones `nix build` cannot see: the
derivation succeeds whether or not the executable is where Info.plist says,
whether or not the plist parses, and whether or not the binaries still
resolve their libraries out of /nix/store -- which works on the machine that
built them and on no machine that did not.
tests/smoke.sh builds an .app around nixpkgs#hello (tiny, cached, and still
links a non-system dylib so the linkage rewrite is real), asserts the
contract, and runs it.
Two assertions are worth calling out.
"Every dylib dep resolves to a file inside the .app" exists because the
obvious check is a trap: delete Contents/lib and the app still prints its
greeting, because dyld quietly falls back to the shared cache's
/usr/lib/libiconv.2.dylib. Naming deps @loader_path/... proves nothing on
its own; the names have to land on files that are actually in the bundle.
"qtCliApp and qtApp produce identical .app contents" pins down the claim
that guiApp is a Linux-only knob. If a Linux-only flag ever starts changing
macOS output, that is where it shows up.
Each assertion was checked against the pre-bump tree or against a
deliberately broken bundler: dropping the Contents/lib symlink, pointing the
wrapper at a missing binary, malforming the plist, and copying the unbundled
derivation instead of the bundle each turn the relevant check red.
* ci: use DeterminateSystems nix installer on macos-latest
cachix/install-nix-action@v27 fails on current macos-latest runners with
`_nixbld1 already exists` / eDSRecordAlreadyExists during the build-user
setup. Same switch basecamp and the design-system already made for their
Darwin jobs.
Co-authored-by: Cursor <cursoragent@cursor.com>
---------
Co-authored-by: Cursor <cursoragent@cursor.com>