| 24 Oct 2025 |
 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 |
| samasaur | yay okay it works | 05:16:13 |
| samasaur | https://github.com/NixOS/nixpkgs/pull/455458 | 05:43:51 |
 K900 | I kinda like the not-patch route | 07:07:08 |
| K900 | But maybe @emily or @Randy Eckenrode have opinions | 07:07:21 |
| K900 | I don't even know if it makes any sense to set that globally | 07:08:34 |
| K900 | My intuition says "this is probably some sort of attempted purity hack" | 07:08:48 |
| samasaur | i was in a patch-based mindset because i found the upstream commit first and wanted to fetchpatch it, but since it doesn't work as-is I don't really care | 07:09:17 |
| samasaur | my concern with setting it globally would be that some other part of qtbase needs the "prefer library over framework" behavior but evidently that seems not to be the case | 07:10:02 |
| samasaur | FWIW the cmakeFlags approach is quite literally just:
diff --git a/pkgs/development/libraries/qt-6/modules/qtbase/default.nix b/pkgs/development/libraries/qt-6/modules/qtbase/default.nix
index ab35d1906f73..0ab2fd0b4a38 100644
--- a/pkgs/development/libraries/qt-6/modules/qtbase/default.nix
+++ b/pkgs/development/libraries/qt-6/modules/qtbase/default.nix
@@ -292,6 +292,8 @@ stdenv.mkDerivation rec {
# When this variable is not set, cmake tries to execute xcodebuild
# to query the version.
"-DQT_INTERNAL_XCODE_VERSION=0.1"
+
+ "-DCMAKE_FIND_FRAMEWORK=FIRST"
]
++ lib.optionals isCrossBuild [
"-DQT_HOST_PATH=${pkgsBuildBuild.qt6.qtbase}"
| 07:16:06 |
