Two darwin packaging bugs prevented the macOS viewer from installing:
1. The postPatch appends `mv "$APPROOT" "$SRCDIR/"` to release/makemacapp.in,
but the script ends with `exit`, which fires an EXIT trap that `rm -rf`s
the temp dir. The appended move was unreachable dead code after `exit`, so
the freshly built `TigerVNC.app` was deleted before it could be staged.
Extend the gawk filter to also drop the trailing `exit` so the move runs.
2. postInstall looked for `TigerVNC Viewer ${version}.app`, but upstream's
APPROOT is `TigerVNC.app`. Update the move and the wrapper's `open` path.
Now that FLTK installs a usable CMake config on darwin (previous commit),
these two fixes let tigervnc configure, build, and install the viewer .app
end-to-end, so drop `broken = stdenv.hostPlatform.isDarwin`.
Assisted-by: Claude-Code:GLM-5.2
Upstream hard-codes the CMake package config install path to
`FLTK.framework/Resources/CMake` on Apple (CMake/setup.cmake), but we build
FLTK as plain shared dylibs, so no framework target is ever created. That
path then becomes an empty `FLTK.framework/` directory holding only the
CMake config files -- no Mach-O binary, no `Headers/`.
Downstream `find_package(FLTK)` (module mode) resolves the main FLTK
library to that bare directory, and the linker fails with
`file cannot be mmap()ed, errno=22`, which surfaces in consumers such as
tigervnc as a misleading "Incompatible version of FLTK".
Install the package config to the standard `lib/cmake/FLTK` location
instead, which also lets config-mode `find_package(FLTK)` work, and drop
the now-unnecessary move of the (no longer created) framework stub.
Assisted-by: Claude-Code:GLM-5.2
f
use buildFHSEnv for linking instead of patchelf. this ensures that krisp
will load properly (NixOS#195512) and avoids violating Discord's ToS.
creates a new wrapper.nix file to hold variables shared across platforms (e.g.
stageModules, disableBreakingUpdates, passthru). when called with
useFHSEnv = false, this will callPackage either linux.nix or darwin.nix
as appropriate
when called with useFHSEnv = true on linux (the default), it will
instead output a derivation built using buildFHSEnv, that exposes the
inner linux.nix package as an overrideable attribute
with both approaches, the underlying mkDerivation is overridable using
the "unwrapped" package argument, and exposed through
passthru.unwrapped
useFHSEnv defaults to *and is asserted to be* false on darwin, due to a
lack of the buildFHSEnv utility
additionally contains some general formatting cleanup and
standardization of arguments across files
Selenium Manager does not ship a binary for linux/loongarch64, causing
test_errors_if_not_file to fail with "Unsupported platform/architecture
combination: linux/loongarch64" instead of the expected "Unable to obtain
working Selenium Manager binary". This is the same issue already worked
around for aarch64-linux.
