| 24 Oct 2025 |
 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 |
| samasaur | maybe the first time Network.framework is actually used by qt? | 05:07:25 |
| samasaur | regardless I think this patch fixes it. if my build ever completes we will know for sure | 05:08:56 |
