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.
This ensures that libraries that are built with brewed LLVM but not
included in the Command Line Tools/Xcode (e.g. libomp) can be found
during a build, while still using system libraries for the essential
stuff (e.g. libc++)
We found an issue in Linuxbrew/homebrew-core#3366 where the addition of "/usr/lib/pkg-config" causes compilation issues if system pkg-config files are in that directory on Linux. Removing the line from here and adding it into the mac superenv.
