| 25 Oct 2025 |
 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 |
| samasaur | it is part of a PR that was mostly purity hacks but i think the logic for setting it to LAST globally is actually just entirely wrong now that frameworks from the SDK are included by default. like it kinda makes sense in a darwin.apple_sdk.frameworks world where frameworks are usually not available (though it should fall back to libraries anyway in that case?), but with the SDK included as an input to every package it just doesn't make sense anymore | 07:30:51 |
| samasaur | which is even supported by that comment saying "on macOS we want to prefer Unix-style headers to Frameworks because we usually do not package the framework" | 07:31:18 |
| K900 | Yeeeeeeeeeeah what the fuck | 07:31:22 |
| samasaur | because we do now package the frameworks | 07:31:23 |
| samasaur | 
Download image.png | 07:31:41 |
| samasaur | this will be fun | 07:31:51 |
| samasaur | (dropping that flag from the setup hook) | 07:32:31 |
