| 24 Oct 2025 |
 samasaur | i think you may have | 05:23:09 |
| samasaur | patching this function down to just set(${out_var} "-framework ${framework_name}" PARENT_SCOPE) makes everything build | 05:23:51 |
| samasaur | and i'm not sure how to test that all the frameworks work but prismlauncher opens at least | 05:24:11 |
| samasaur | but i think this is fine? because all the frameworks should be there from the SDK anyway, right? | 05:27:37 |
| samasaur | and if they're missing it will still fail at build time, right? just not at configure time | 05:28:07 |
| samasaur | will revisit tomorrow | 05:35:03 |
 EsperLily [she/her] | hmm, xcrun from a nix-shell on current master is printing a warning that isn't happening with nixpkgs from a few days ago (warning: unhandled Platform key FamilyDisplayName) | 08:08:47 |
| EsperLily [she/her] | i can't be 100% positive since i'd have to actually rebuild the whole darwin SDK to be sure, but I think this was caused by https://github.com/NixOS/nixpkgs/pull/445094 | 08:23:07 |
| EsperLily [she/her] | looking at my Xcode developer dir, I also see that FamilyDisplayName is found within ./Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/SDKSettings.plist (as the key PlatformFamilyDisplayName) and it's not there in the nixpkgs SDK version, so I'm wondering if maybe that's the difference? | 08:30:53 |
| EsperLily [she/her] | hmm, i just copied the nixpkgs SDK and edited that file to insert PlatformFamilyDisplayName and it didn't fix it. But editing Platforms/MacOSX.platform/Info.plist to remove FamilyDisplayName does remove the warning | 08:34:59 |
 emily | ok then maybe look at my CMake patches | 10:23:57 |
| emily | I don't feel good about doing that to Qt without understanding why | 10:24:04 |
| emily | my guess is it might actually be an upstream CMake change | 10:24:20 |
| emily | but if not then it's plausible it's the stuff I did to get rid of the mangling hook for the 4 update | 10:24:35 |
 Randy Eckenrode | It was. I added it in preparation for supporting Swift Build. If I got the name wrong, I can fix it. I was going by the keys it references in its source. If people are that annoyed by the warnings in xcbuild, they can be patched out. | 10:40:09 |
| emily | I take it Swift Build has no xcrun or xcode-select, right? | 10:51:30 |
 Ihar Hrachyshka | now that target sdk is 14.4, should we make blas == Accelerate? | 10:51:59 |
| emily | we should keep a list of "if you feel like writing a compatible FOSS replacement for this Apple tool we will love you forever" | 10:52:12 |
| emily | PlistBuddy, xcrun, ibtool, ... | 10:52:28 |
| emily | ditto... | 10:52:31 |
| emily | the dearly missed paparodeo ran into crashes with some packages using Accelerate and had to give them OpenBLAS explicitly. I'm not sure why | 10:52:58 |
| emily | I'd probably want us to investigate those before doing the switch | 10:53:10 |
| Randy Eckenrode | It’s just the engine used by Xcode. It provides a binary, but the CLI is incompatible. Longer term, we could use Swift Build to provide a compatible(-enough) xcode-build. | 11:03:29 |
| Randy Eckenrode | Same for xcrun. Just write a good enough replacement in Swift. | 11:04:02 |
| Randy Eckenrode | It’s not fully compatible. There are some differences numerically. I ran into test failures trying to use it with something and didn’t bother after that. | 11:04:53 |
| Ihar Hrachyshka | numpy (in staging) is now Accelerate since it was picked up automatically by the build system. scipy is not (I have a patch for this).
when you say "test failures", do you mean nix build invoked or something else? (basically, q is: are we ok to switch a package - or packages - if they build / pass test suites) | 11:06:04 |
| Randy Eckenrode | It was the package’s test suite. I can’t remember whether it was numpy or scipy, but it was a Python package. | 11:07:21 |
| Ihar Hrachyshka | ack. scipy and numpy pass. maybe it's something else. | 11:08:36 |
| Randy Eckenrode | They could have also fixed support. | 11:08:56 |
| Randy Eckenrode | If the tests pass, switching seems reasonable, especially if we are now at the supported platform level. | 11:09:44 |
