Some formulae declare multiple Python dependencies, and they can appear
in any order in the `deps` array. Let's make sure to prefer the newest
one when adding their `libexec/"bin"` directory to `PATH`.
When Homebrew/homebrew-core#107517 is merged, builds will no longer be
able to find `python@3.9` as `python3`. This is also what is likely to
happen to `python@3.10` when we add a `python@3.11`.
This is likely to break many builds, so let's make sure they can keep
finding a `python3` for formulae that don't have a dependency on the
latest Python3.
This is arguably something we should've done earlier: it also means that
builds that go looking for an unversioned `python` end up finding our
Python3 (whenever present in the build environment) instead of, say,
`/usr/bin/python` which is typically Python2.
This makes `ENV.O{1,0}` behave like `ENV.deparallelize`.
This should also allow us to build libgcrypt's jitter entropy collector,
which we currently disable because it interacts poorly with our compiler
shims. See #11201.
Some formulae are able to detect the features of the runtime CPU, and
execute code accordingly. This typically entails 1) the detection of
features of the build-time CPU in order to determine the targets that
the compiler can generate code for, and 2) generating code for the
targets that the compiler can support.
Our filtering of optimization flags can cause misdetection of compiler
features, leading to failed builds [1], and miscompilation even when the
build does not fail [2].
Let's try to fix this by allowing formulae to declare
`ENV.runtime_cpu_detection` which skips the filtering of `-march` and
related flags.
I've also skipped the filtering of the optimisation
level, since it seems to me that if upstream maintainers have gone to
the lengths of writing code that detects runtime hardware, they probably
also know better about appropriate `-O` flags to use.
This is a partial list of formulae that should make use of this feature:
1. apache-arrow
2. fftw
3. gromacs
4. open-mpi
5. openblas
Partially resolvesHomebrew/homebrew-core#76537.
[1] open-mpi/ompi#8306 and linked issues/PRs
[2] Homebrew/homebrew-core#76537
Currently, Homebrew recognises only the architectures listed in
`hardware.rb`. [1] Attempting to pass an unrecognised architecture to
`--bottle-arch` while building a bottle returns an error.
Let's change that by passing unrecognised bottle arches to the compiler
instead of immediately failing with a `CannotInstallFormulaError`.
Partially resolves#5815.
[1] 64b6846d60/Library/Homebrew/hardware.rb (L28-L42)
[g]libtoolize looks for m4 using the environment variable M4. When
that isn't set, it looks for m4 in PATH.
However, when libtool is a build dependency but m4 is not, m4 will
not be found in PATH. Since it is currently not set in the
environment by superenv, this causes some builds to fail.
Closes https://github.com/Homebrew/homebrew-core/pull/73932.
Building automake fails with autoconf 2.70+, when autoconf is used with
macOS m4. It therefore makes sense for autoconf to depend on brewed m4.
However, without the change proposed here, the setting of the M4
environment variable in superenv breaks the automake build.
Related: https://github.com/Homebrew/homebrew-core/pull/73797
These are still used in Homebrew/homebrew-core. The others are either
- default (Os on macOS, O2 on Linux)
- less reliable than the default (O3)
While we're here, also remove an outdated `ncurses_define` comment.
This probably has to wait until 2.7.0 now and will require a bunch of
formula changes/deprecations but we should probably start moving in this
direction given we're not installing any of these on our CI any more.
This reduces the deviation in compilation flags on a given OS between
users and between bottling/not bottling to provide a consistent
behaviour for debugging and support.
