Fix zarith compilation on arm64 homebrew

[avsm]

Homebrew installs in /opt/homebrew by default on arm64.
This logic would ideally be baked into a configure script somewhere,
but for now it unblocks Zarith installation using opam on Mac M1s.

[kit-ty-kate]

It might be interesting to use pkg-config instead: #18129 (comment)

[camelus]

Commit: 53c0655

A pull request by opam-seasoned @avsm.

☀️ All lint checks passed 53c0655

• These packages passed lint tests: zarith.1.12

---

☀️ Installability check (+0)

[mseri]

@kit-ty-kate do you know what is going on in the CI? It shows failure messages even if it succeeds. For example mirage-dns.3.0.1 is marked as failed with [ERROR] Sorry, resolution of the request timed out. but it has that message seemingly in a depext step in between two successes:

The following actions will be performed:
  - remove mirage-dns 3.0.1

<><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><><><>
-> removed   mirage-dns.3.0.1
Done.
# Run eval $(opam env) to update the current shell environment
# Detecting depexts using vars: arch=x86_64, os=linux, os-distribution=debian, os-family=debian
[ERROR] Sorry, resolution of the request timed out.
        Try to specify a simpler request, use a different solver, or increase the allowed time by setting OPAMSOLVERTIMEOUT to a bigger value (currently, it is set to 500.0 seconds).
Command failed: opam list --readonly --with-test --external  '--resolve=mirage-dns.3.0.1' returned 60
[NOTE] mirage-dns.3.0.1 is not installed.

Nothing to do.
The following actions will be performed:
  - install mirage-dns 3.0.1

<><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Processing  1/3:
-> retrieved mirage-dns.3.0.1  (cached)
Processing  2/3: [mirage-dns: jbuilder build]
+ /home/opam/.opam/4.11/bin/jbuilder "build" "-p" "mirage-dns" "-j" "47" (CWD=/home/opam/.opam/4.11/.opam-switch/build/mirage-dns.3.0.1)
-> compiled  mirage-dns.3.0.1
-> installed mirage-dns.3.0.1
Done.

[kit-ty-kate]

That's a feature added in ocurrent/opam-repo-ci#66. The reasoning is that opam 2.1 is able to go past most solver timeouts and using it when encountering a timeout with opam 2.0 allows us to see if we're missing an actual failure, however we still want to fail if it times-out with opam 2.0 as it is currently the version of opam most people use.

[mseri]

Oh, I see. Awesome, thanks!

[avsm]

@kit-ty-kate a fine suggestion, but not one to solve in opam-repository -- I'd prefer upstream Zarith do that as part of their configuration strategy since pkg-config would complicate cross-compilation (e.g. for Mirage).

@xavierleroy @antoinemine, is the current PR with you? @TheLortex is also looking at adapting the recent Zarith changes to the Mirage cross-compilation friendly version, so perhaps he can look at Kate's suggestion about pkg-config and contribute any findings back to the Zarith repository.

[kit-ty-kate]

I suggested it in the PR porting zarith to dune a few weeks ago: ocaml/Zarith#73 (comment)

[kit-ty-kate]

Looks ok in the meantime. Thanks!

[xavierleroy]

I was summoned in this discussion. I have no problems with the proposed change. But I was expecting something better: conf-gmp should export the correct paths for include files and for library files (obtained by pkg-config or any other means), and the OPAM package for ZArith should use these paths. I thought this kind of information sharing was possible in OPAM, but maybe I'm confused.

Instead, the way things are done today, some logic is duplicated between the conf-gmp and zarith packages, and both packages do a rather poor job at detection, if I may say so. (Neither package tries to use pkg-config...)

Re: whether ZArith itself should try to use pkg-config during its own configuration: quite possibly, I'll think about that. But a better conf-gmp package would benefit other OPAM packages that use GMP. (Not sure there are any.) So, there's a ZArith issue, but also an OPAM package issue.