| 24 Oct 2025 |
 Randy Eckenrode | So, somewhat related, if I want to be ready for allowing scopes in by-name, what’s the best approach to use? I’m thinking of a swiftPackages scope. | 02:54:16 |
 emily | I think just do whatever you were doing pretty much | 02:56:36 |
| emily | we are already having to think about how to port the existing scopes | 02:56:45 |
| emily | which do some pretty gnarly things | 02:56:53 |
| emily | if you can try to avoid putting random things that aren't packages in the scope that's nice | 02:57:07 |
| emily | and use makeScopeWithSplicing | 02:57:31 |
| Randy Eckenrode | That’s pretty much what I was doing. The plan was to rely on the scope to handle cross, so I just need to provide swiftPackages.stdlib. | 03:04:07 |
| Randy Eckenrode | For example. | 03:04:12 |
| Randy Eckenrode | So don’t put functions in the scope? Can they be in packages? While I want to move away from swiftpm2nix, I plan to keep it for compatibility. | 03:05:21 |
| emily | generic builder functions are surely something we'll have to handle in some form or another | 03:06:17 |
| emily | and passthru functions surely can't cause any more issues than they already do (you can put 'em in by-name already) | 03:06:31 |
| Randy Eckenrode | It has some boilerplate stuff it exports IIRC. | 03:06:53 |
| emily | realistically each scope will need to be manually looked at | 03:07:09 |
| emily | and the existing ones have pretty gnarly stuff already | 03:07:22 |
| emily | I wouldn't anticipate major issues unless yo utry to do super magic things | 03:07:40 |
| emily | it's mostly just been a question of how we need to extend by-name and what that mechanism should look like | 03:07:59 |
 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 |
