Recommend the use of `on_macos` and `on_linux` unless we're in
`def install`, `def post_install` or `test do` in which case recommend
`OS.mac?` and `OS.linux?` instead.
We have a handful of of formulae that do `std_cmake_args.reject` to
override some of flags (e.g. emscripten, icemon, ortp, qt, klee,
watchman).
Let's try to simplify some of this code by allowing these formulae to
override these flags by passing arguments to `std_cmake_args`.
While we're here, let's update the type signature of `std_cargo_args`.
This method takes an optional array of `Pathnames`s or `Strings`s and
extracts the native slice from the specified universal binary. If no
parameter is supplied, this is done on all compatible universal binaries
in a formula's keg.
`deuniversalize_machos` is a no-op on Linux.
I still need to look into a) error handling, and b) whether using this
method requires codesigning on ARM.
I've also added signatures to the methods in `extend/os/linux/formula`.
A number of formulae use a variant of `Time.now` to generate the build
time of the formula. Let's define a method to make sure that:
1. it uses `SOURCE_DATE_EPOCH` whenever available; and,
2. it uses `utc`.
Both should help with build reproducibility.
See Homebrew/homebrew-core#80608.
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.
These flags include basic compiler optimization flags without which software can get built completely unoptimized.
While the shims appear to add their own optimization flag on macOS (at least, based on my ARM testing), they do not in the default Linux build which results in CMake packages like LLVM being built without optimizations. This both results in a very large bottle and exceedingly bad performance.
This seems like the best fix to me, as the shims already seem to have the necessary logic to *re-map* optimization flag levels to what Homebrew prefers for platforms like macOS, and so leaving CMake alone to just do its thing seems like the cleanest solution. But I'm open to other suggested fixes if needed.
I will note that without this, LLVM and any other CMake-built software on Linux is ... mostly unusable for me.