wrf-cmake / homebrew-wrf Goto Github PK

The current formula is based on WRF-CMake 4.0.3 where clang was not supported.
The current formula can only be successfully be built using the latest commits in wrf-cmake branch. To build from the latest commit in wrf-cmake, users can pass the --HEAD flag when building. I will update the docs accordingly for now until we release 4.1.0

@zbeekman You mentioned in WRF-CMake/wrf#22 that it would be awesome if WRF-CMake makes it into the Homebrew package manager, which would mean upstreaming the formula to homebrew-core and then letting the homebrew build bots create bottles (=binary distributions). Is that correct?

I thought about this a bit more and identified a potential blocker. First, some context.

Currently when users build WRF-CMake from source then they are more or less on their own, meaning that if they have an incompatible compiler or dependency version on their system then they have to fix it and we can't do much about it. We could mention CI-tested compiler and library versions somewhere, but that's a bonus. In general it all works out and it's nearly never an issue, but it may be.

When users download our pre-built binaries then they can be sure that this exact binary including all bundled dependencies has been tested and validated by our CI setup. There is nearly nothing that can go wrong there, apart from having the wrong mpi runner installed, but that's it.

With Homebrew bottles, we don't have this gating process and also don't have control over library versions. We can influence the compiler to some degree but it's not an ultimate solution.

Given all this, does it make sense at all to try to move the WRF-CMake formula to homebrew-core? How could we prevent that new bottles are built that accidentally lead to breaks that are only visible at runtime? Keep in mind that our CI-based tests take many hours to run and they couldn't be integrated into the test part of the formula. We could have a very simple "doesn't crash when running a super-short simulation" test but this is tricky as well, since some failure scenarios become only visible in debug mode and otherwise just happily corrupt memory in release mode which may not become obvious for very small tests.

In summary, we want to be careful when releasing binary distributions and I don't see a good way to have sufficient quality control with brew bottles in this case.

WRF-CMake failed to build on my MacBook Air M1 after running:

brew tap wrf-cmake/wrf
brew install wrf-cmake -v

I am unsure why it failed, any assistance would be appreciated.

Below is the log file:
CMakeOutput.log

When using Homebrew to compile on systems with multiple compilers CMake will pick the first compiler in the PATH. Instead, we should enforce CMake to use the same compilers as defined in the in the Homebrew formula.