extconf: respect AR and RANLIB in recipes on darwin

[joshheinrichs-shopify]

What problem is this PR intended to solve?

When using Nix on Darwin, we ideally should be latching onto the Nix-provided AR and RANLIB. Without this, when blocking Xcode via sandbox-exec, I see errors like this while attempting to install the gem, since we end up using the default ar and runlib

xcode-select: note: No developer tools were found, requesting install.
If developer tools are located at a non-default location on disk, use `sudo xcode-select --switch path/to/Xcode.app` to specify the Xcode that you wish to use for command line developer tools, and cancel the installation dialog.
See `man xcode-select` for more details.

Have you included adequate test coverage?

No but this seems relatively harmless?

Does this change affect the behavior of either the C or the Java implementations?

No

[flavorjones]

Hi @joshheinrichs-shopify, thanks for opening this.

Do you know if there are any github actions that we could use to test Nix-on-Darwin? (For example, we're using vmactions/freebsd-vm@v1 to test FreeBSD.)

I put in a lot of work over the past few years to thoroughly exercise compilation on supported platforms, and that coverage has allowed me to confidently make changes to extconf.rb. I'd prefer not to merge this without adding some test coverage to prevent regressing, if possible.

[flavorjones]

I'm also curious: can you share why you're not using precompiled gems?

[joshheinrichs-shopify]

thanks for taking a look at this! sorry for the slow response -- was on vacation last week.

Do you know if there are any github actions that we could use to test Nix-on-Darwin? (For example, we're using vmactions/freebsd-vm@v1 to test FreeBSD.)

there look to be at least a few options:

• https://github.com/cachix/install-nix-action
• https://github.com/DeterminateSystems/nix-installer-action

both appear to support darwin. the latter as far as i understand is a downstream enterprisey distribution of nix so i went with the former.

I'm also curious: can you share why you're not using precompiled gems?

this appears to be a consequence of us being on a preview version of ruby (3.4.0-preview2).

[flavorjones]

Looks good! I kicked off CI.

[flavorjones]

CI is failing, see my suggestions inline.

[flavorjones]

Kicked off CI again.

[flavorjones]

@joshheinrichs-shopify CI is failing. Looks like a tricky one. My guess is that there's inconsistent header usage: xmlSwitchEncodingName was added in libxml2 v2.13.0, and so the extconf is checking for its existence using a "modern" libxml2 (maybe Nokogiri's own vendored headers?), but then compiling against something older than that (maybe nix's system headers?). I have no idea what nix package is being linked- and compiled-against so I can't verify that hunch, but something like that is likely the cause.

[joshheinrichs-shopify]

hmm looks like that failing test is latching onto xcode for some reason. taking a look...

[flavorjones]

LOL, naming things is hard

[flavorjones]

Just kicked CI and it looks like the darwin-nix-enabled build is green! If everything goes green I'll merge.

[flavorjones]

Thank you! This will be in v1.17.0 when it ships (hopefully very very soon).