extconf: respect AR and RANLIB in recipes on darwin #3338
Conversation
When using Nix on Darwin, we ideally should be latching onto the Nix-provided AR and RANLIB.
There was a problem hiding this comment.
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.
| @@ -928,7 +928,10 @@ def configure | |||
| end | |||
|
|
|||
| if darwin? && !cross_build_p | |||
| recipe.configure_options += ["RANLIB=/usr/bin/ranlib", "AR=/usr/bin/ar"] | |||
| recipe.configure_options += [ | |||
| "RANLIB=#{ENV.fetch("RANLIB", "/usr/bin/ranlib")}", | |||
There was a problem hiding this comment.
For libxml2's configure script, if an environment variable like RANLIB is set, then it doesn't need to be passed explicitly to the configure command. Can you restructure this to something like the following
recipe.configure_options << "RANLIB=/usr/bin/ranlib" unless ENV.key?("RANLIB")
recipe.configure_options << "AR=/usr/bin/ar" unless ENV.key?("AR")| @@ -969,7 +972,10 @@ def configure | |||
| cflags = concat_flags(ENV["CFLAGS"], "-O2", "-U_FORTIFY_SOURCE", "-g") | |||
|
|
|||
| if darwin? && !cross_build_p | |||
| recipe.configure_options += ["RANLIB=/usr/bin/ranlib", "AR=/usr/bin/ar"] | |||
| recipe.configure_options += [ | |||
| "RANLIB=#{ENV.fetch("RANLIB", "/usr/bin/ranlib")}", | |||
There was a problem hiding this comment.
Same here for libxslt's configure script.
|
I'm also curious: can you share why you're not using precompiled gems? |
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 defaultarandrunlibHave 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