| 24 Oct 2025 |
 Randy Eckenrode | Rust demoted it to tier 2. The GitHub runner was pulled then restored, but it is limited to macOS 15. Who knows for how long. Once it’s gone, Intel support will probably start bitrotting. | 16:59:23 |
| Randy Eckenrode | From the nixpkgs side, x86_64-darwin is the slowest platform to build. Being able to drop it will free up builders to build aarch64-darwin, which should make cycles go faster. | 17:00:23 |
|  stderr joined the room. | 18:00:15 |
 EsperLily [she/her] | the name looks right, although i suppose i didn't actually check to make sure there wasn't some hidden character or some typo i just didn't see. i really don't know why xcrun is printing a warning about that with the nixpkgs SDK when the Xcode SDK has what looks like the exact same key. Does Swift Build care about that particular key?
My bigger concern is what I mentioned in the Nixpkgs / NixOS contributions room, which is that when I try to use Xcode to build a project with the nixpkgs SDK (not Xcode-in-nixpkgs but /usr/bin/xcodebuild, though I don't know if it actually makes a difference), I end up with what looks like a neverending stream of these warnings, several per second, with no other output. I don't know if the warning itself is actually a problem here or if there's some other reason why Xcode doesn't seem to actually be doing anything except printing these warnings
| 20:08:59 |
 emily | /usr/bin/xcodebuild will probably indirect through $DEVELOPER_DIR? | 20:18:41 |
| emily | so is probably calling into xcbuild.xcrun etc. | 20:18:54 |
| EsperLily [she/her] | /usr/bin/xcrun produces the same warning | 20:19:24 |
| EsperLily [she/her] | oh wow what, /usr/bin/xcrun actually invokes xcbuild.xcrun? | 20:20:19 |
| emily | everything in /usr/bin is just a stub that looks up the current developer directory | 20:20:33 |
| EsperLily [she/her] | but xcrun -find xcrun doesn't find anything | 20:20:33 |
| EsperLily [she/her] | yeah it's a stub that looks it up with the xcrun machinery. xcrun should be the one thing that isn't a stub | 20:20:46 |
| emily | shion:/v/f/1/j/T/tmp.KkX7NHuPxH
❭ mkdir -p usr/bin
shion:/v/f/1/j/T/tmp.KkX7NHuPxH
❭ cat >usr/bin/xcrun
#!/usr/bin/env bash
echo oops
shion:/v/f/1/j/T/tmp.KkX7NHuPxH
❭ chmod +x usr/bin/xcrun
shion:/v/f/1/j/T/tmp.KkX7NHuPxH
❭ DEVELOPER_DIR=(pwd) /usr/bin/xcrun
oops
| 20:21:50 |
| emily | I think it recurses if there's another xcrun. | 20:22:08 |
| emily | not even --help etc. do anything. | 20:22:16 |
| EsperLily [she/her] | wow | 20:22:41 |
| emily | I think /usr/bin/xcrun is exactly like /usr/bin/clang | 20:22:48 |
| emily | they call the thing from libselect or whatever it's called to find the xcrun path relative to the developer dir and then run it | 20:22:59 |
| emily | and then the rest of the library calls are in that binary | 20:23:13 |
| emily | shion:/v/f/1/j/T/tmp.KkX7NHuPxH
❭ DEVELOPER_DIR=(pwd) /usr/bin/clang
oops
| 20:23:16 |
| emily | so my guess is there's an infinite recursion where it's trying to get xcrun to run something but then xcrun can't find the thing and it falls back to /usr/bin which then etc… | 20:24:11 |
| EsperLily [she/her] | but there is no xcrun in the normal Xcode developer dir (there is a usr/lib/libxcrun.dylib though) | 20:24:19 |
| emily | hmm maybe it's a compatibility thing for old Xcodes | 20:24:33 |
| emily | if there's an xcrun binary, run it, otherwise use the library | 20:24:40 |
| EsperLily [she/her] | maybe so | 20:24:44 |
| EsperLily [she/her] | huh, if i modify the nixpkgs SDK to remove xcrun, /usr/bin/xcrun actually complains about the missing xcrun | 20:25:53 |
| EsperLily [she/her] | if i symlink in the libxcrun.dylib then it prints a different error about how it can't find the Xcode installation, that's interesting. now I'm wondering what's in the version of the SDK installed by CommandLineTools (but i'm not willing to install that to find out) | 20:27:45 |
| EsperLily [she/her] | FWIW in https://github.com/NixOS/nixpkgs/issues/376958 at least one person now gets that warning printed in their shell (which would suggest they now have their DEVELOPER_DIR set to the nixpkgs SDK for some reason), so it probably is worth patching it out. https://github.com/facebookarchive/xcbuild/blob/dbaee552d2f13640773eb1ad3c79c0d2aca7229c/Libraries/xcsdk/Sources/SDK/Platform.cpp#L176 looks like the spot where those keys are read, so it just needs an entry added for FamilyDisplayName | 20:31:08 |
| 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 |
