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
BuildPulse is trying to find flaky tests for us but, given the previous
model of using `rspec-retry`, it would rarely find them. Instead, let's
try to always rerun `brew tests` multiple times, report to BuildPulse
each time (by moving the reporting logic into `brew tests`) and disable
`rspec-retry` when using BuildPulse.
While we're here, let's enable `rspec-retry` locally so we don't have
flaky tests biting maintainers/contributors there.
A user may wish to use two use two brew-installed Python packages
together. For example, one might want to `import numpy` when using
`jupyterlab` or `ptpython`.
Currently, the only ways to do this I'm aware of is with some hacking of
`PYTHONPATH` or the creation of `.pth` files in a formula's prefix.
A better solution is to allow the virtualenvs that `brew` creates to
have access to system site-packages by default, so that `import numpy`
inside `ptpython` or `jupyterlab` just works.
Partially resolvesHomebrew/homebrew-core#76950.
Arch-specific build tool formulae (https://github.com/Homebrew/homebrew-core/pull/79874) install their info files in `#{info}/<arch>` to avoid conflicts with the main tool formulae.
However, the info cleaner only removes `#{info}/dir`, so each tool's bottle includes `#{info}/<arch>/dir`, which causes install-time conflicts.
This PR fixes that by deleting all `dir`s under `#{info}`.
Before:
```
==> Cleaning
[...]
==> Fixing /usr/local/Cellar/i686-elf-binutils/2.36.1_1/lib/i686-elf/bfd-plugins/libdep.so permissions from 755 to 444
==> Finishing up
```
After:
```
==> Cleaning
[...]
==> Fixing /usr/local/Cellar/i686-elf-binutils/2.36.1_1/lib/i686-elf/bfd-plugins/libdep.so permissions from 755 to 444
rm /usr/local/Cellar/i686-elf-binutils/2.36.1_1/share/info/i686-elf/dir
==> Finishing up
```
Currently, we copy `config.log` and `CMakeCache.txt` from the root of
the source tree into the the logs generated by the build. This has three
shortcomings:
1. These files are not necessarily found where we look. This is often
the case with a CMake build, but can occur with an Autotools build
as well (e.g. GCC, or any other out-of-tree build).
2. There may be several of these files scattered throughout the build
tree. This occurs, for example, when the build itself invokes
`configure` or `cmake` as part of the build process.
3. We don't copy `CMakeOutput.log` or `CMakeError.log`, which are
usually more informative about what happened during the CMake
invocation. It is not sufficient to add them to the array of log
files that we copy because these are never found at the source root,
even when building in-tree.
Let's rectify this by copying all instances of these files that can be
found in the source tree. Since there will inevitably be duplicate file
names, we also store them in the log directory using the same relative
paths from the source root. [1] This has the added benefit of providing
context for these log files.
[1] For example, if `CMakeOutput.log` can be found in `build/CMakeFiles`
relative to the source root, then that will also be where it will be
stored in the log directory.
