nix: use -ld_new on macOS

[thoughtpolice]

The new parallel macOS linker reduces link time for the debug jj binary from 3s to 0.7s on my M2 Macbook Air, which is a significant reduction for nearly no cost at all.

However, enabling it is rather strange because we have to give a full path to the /Applications directory, and I don't know of a good way to encapsulate it with existing Nix primitives inside Nixpkgs...

This change requires Sonoma and Xcode 15, but in theory I think we could target a lower macOS SDK version in order to produce binaries that are more backwards compatible, so the only real cost is that developers who also use Nix would require Sonoma.

Checklist

If applicable:

• I have updated CHANGELOG.md
• I have updated the documentation (README.md, docs/, demos/)
• I have updated the config schema (cli/src/config-schema.json)
• I have added tests to cover my changes

[thoughtpolice]

This change requires Sonoma and Xcode 15, but in theory I think we could target a lower macOS SDK version in order to produce binaries that are more backwards compatible, so the only real cost is that developers who also use Nix would require Sonoma.

Actually this... doesn't really matter because it's purely for the devShell. So maybe this fix can go ahead and be merged, but I'll think about it some more.

[emilazy]

This would make me happy. Does it speed up the build for tests meaningfully too?

[thoughtpolice]

This would make me happy. Does it speed up the build for tests meaningfully too?

Probably, but I haven't looked at that exactly. That said this is a small and easy change to make so if someone else likes it, I think it can be merged and backed out if it turns out bad.

[emilazy]

I think you can just use xcrun ld …, by the way. That should work if the user has another developer directory. Or /usr/bin/ld, even.

[emilazy]

Oh, I guess you can’t use zcrun because Rust is calling it. /usr/bin/ld should work though; those are stubs that redirect to the currently‐active developer directory.

[thoughtpolice]

/usr/bin/ld should work though; those are stubs that redirect to the currently‐active developer directory.

Sure does work, please take a look. /cc'ing @necauqua for review too

[emilazy]

Seems to work for me! Just a couple nits…

[emilazy]

By the way, do we know if this breaks pre‐Sonoma or not? I wonder if maybe the older ld(1) just ignores the argument? If not, it’d be nice if we could make this conditional on it working.

[thoughtpolice]

By the way, do we know if this breaks pre‐Sonoma or not? I wonder if maybe the older ld(1) just ignores the argument? If not, it’d be nice if we could make this conditional on it working.

It probably does, but it only applies to nix develop shells which is probably where it's most useful. Normal nix install routes will continue to use the stdenv linker instead and so will anyone using rustup. So, I think we could conditionalize it to make it safer, but we can probably just wait until someone asks for it or reports a build failure.

[emilazy]

Breaking support for everything but the latest macOS release makes me a little nervous, but I guess there’s probably, like, five of us actually using the flake to do Jujutsu development, so… sure, why not wait and see :)

[necauqua]

I've never heard of running nix on Windows, but wouldn't it be better to just have an empty list there in place of a throw? Just so that in the rare case both checks are false, it wouldn't outright fail because we told it to

Other than that, I don't have a Mac, so I can't test, but it looks ok

[emilazy]

You kind of can’t run Nix on Windows at present. The most viable third OS is, I think, FreeBSD? I know people are actively working on support for that but I don’t think there’s much upstream at present and I’d be surprised if they have enough working for the Jujutsu flake to work. Agreed that an empty list is preferable though.

[thoughtpolice]

I reworked it to use an empty list. Thanks!