| 24 Oct 2025 |
EsperLily [she/her] | if i symlink in the libxcrun.dylib then it prints a different error about how it can't find the Xcode installation, that's interesting. now I'm wondering what's in the version of the SDK installed by CommandLineTools (but i'm not willing to install that to find out) | 20:27:45 |
EsperLily [she/her] | FWIW in https://github.com/NixOS/nixpkgs/issues/376958 at least one person now gets that warning printed in their shell (which would suggest they now have their DEVELOPER_DIR set to the nixpkgs SDK for some reason), so it probably is worth patching it out. https://github.com/facebookarchive/xcbuild/blob/dbaee552d2f13640773eb1ad3c79c0d2aca7229c/Libraries/xcsdk/Sources/SDK/Platform.cpp#L176 looks like the spot where those keys are read, so it just needs an entry added for FamilyDisplayName | 20:31:08 |
emily | the CLT SDKs are identical to the Xcode ones I'm pretty sure | 20:39:49 |
emily | it's normal to have DEVELOPER_DIR set in a Nix development shell | 20:40:22 |
emily | (or no build tools would work) | 20:40:32 |
EsperLily [she/her] | they didn't say "Nix development shell" they just said "in my shell" | 20:40:51 |
EsperLily [she/her] | so i assume this is coming from commands being run in a custom prompt | 20:41:17 |
EsperLily [she/her] | like starship testing tool versions or something | 20:41:25 |
EsperLily [she/her] | * like starship testing tool versions or something (edit: actually /usr/bin/git would invoke this machinery too) | 20:43:23 |
emily | I thought you meant the comment with
xsdc-translator on dev [$] via v20.18.1 via ❄️ impure (devenv-shell-env)
but I'd still predict the other person is in a dev shell based on the lack of anything weird-looking in their dotfiles
| 20:47:14 |
emily | you'd have to try quite hard to have something in the Nix store as your global DEVELOPER_DIR | 20:47:46 |
Randy Eckenrode | I was adding all the keys I saw it reference in its source code. If this warning is actually a problem, we can fix it in xcbuild, but I don’t think it will help with the MacVim build. | 21:23:15 |
EsperLily [she/her] | no it doesn't sounds like the cause of the MacVim build issue, i'm going to have to spend more time tracking that down | 21:23:54 |
Randy Eckenrode | And if users are complaining, it can also be patched. | 21:25:39 |
Randy Eckenrode | * | 21:26:14 |
Ihar Hrachyshka | firefox issue is... fun. arm build crashes, x86 (through rosetta) doesn't. some asm fun: https://github.com/NixOS/nixpkgs/issues/453372#issuecomment-3444981832 | 21:53:46 |
| 25 Oct 2025 |
| mio joined the room. | 02:16:32 |
samasaur | qt time again 🫠 | 03:33:00 |
samasaur | AH HA | 03:42:48 |
samasaur | so there are a couple of frameworks that CMake can't find | 03:43:20 |
samasaur | AssetsLibrary, MobileCoreServices, UIKit, WatchKit, Network | 03:43:58 |
samasaur | the first four actually are missing | 03:44:33 |
samasaur | Network.framework actually is in the SDK directory alongside all the other frameworks that it does find | 03:45:01 |
samasaur | what gives? turns out it's not actually failing the NOTFOUND part of the check, it's failing the MATCHES ".framework$" part | 03:45:55 |
samasaur | because (unique among all the frameworks that it "can't find"), when calling find_library(FWNetworkInternal Network), it actually does find something:
/nix/store/9idkk50xhm91i33fzsgg520z5pa8i8dv-apple-sdk-15.5/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.5.sdk/usr/lib/libnetwork.tbd
| 03:46:56 |
samasaur | https://github.com/qt/qtbase/commit/b181132f742a0d212f8ffaf6f8fb48a099ac45dd | 03:50:33 |
samasaur | ...except that we don't set QT_USE_VCPKG | 03:56:00 |
samasaur | like that is the actual issue, but I can't apply that patch directly | 03:56:26 |
samasaur | well it appears to be building | 04:00:38 |
samasaur | issue might be coming from https://github.com/NixOS/nixpkgs/blob/01f116e4df6a15f4ccdffb1bcd41096869fb385c/pkgs/by-name/cm/cmake/setup-hook.sh#L42-L44 ? though it looks like it hasn't been touched for years, so I'm not sure why we'd suddenly be seeing this issue | 05:07:13 |