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 was only used by 2 formuale in homebrew-core.
One formula did not need the flag anymore and the flag was removed
The other formula (rogue) still needs it, the flag was directly
added to the formula.
There is no reason for us to keep this method.
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.
Remove usage where `Homebrew.args` could be used instead or, due to the
`Homebrew.args` parsing, there was dead code that was never executed
(and no-one complained about not working).
Refactor the CLI::Args module so it doesn't have different paths to
check arguments depending on whether the arguments have been parsed or
not. Instead, set the values we need from the global ARGV at
first, global initialisation time where they will be thrown away when
the actual arguments are parsed.
To do this some other general refactoring was needed:
- more methods made private when possible
- e.g. `HEAD?` used consistently instead of `head` before arguments
are parsed.
- formula options are only parsed after named arguments are extracted
