chapel 1.26.0 pre-release #98111
chapel 1.26.0 pre-release #98111
Conversation
Signed-off-by: Tim Zinsky <tim.zinsky@hpe.com>
BrewTestBot
added
the
python
Signed-off-by: Tim Zinsky <tim.zinsky@hpe.com>
Signed-off-by: Tim Zinsky <tim.zinsky@hpe.com>
carlocab
added
prerelease-testing
Adding fix for gcc-5 build failures. Signed-off-by: Tim Zinsky <tim.zinsky@hpe.com>
Formula/chapel.rb
Outdated
| system "echo CHPL_RE2=bundled > chplconfig" | ||
| system "echo CHPL_GMP=system >> chplconfig" | ||
| system "echo CHPL_LLVM_CONFIG=#{HOMEBREW_PREFIX}/opt/llvm@11/bin/llvm-config >> chplconfig" | ||
| system "echo CHPL_LLVM_CONFIG=#{HOMEBREW_PREFIX}/opt/llvm@13/bin/llvm-config >> chplconfig" | ||
| # don't try to set CHPL_LLVM_GCC_PREFIX since the llvm@13 | ||
| # package should be configured to use a reasonable GCC | ||
| system 'echo CHPL_LLVM_GCC_PREFIX="none" >> chplconfig' |
There was a problem hiding this comment.
This could be easier like:
(libexec/"chplconfig").write <<~EOS
CHPL_RE2=bundled
CHPL_GMP=system
EOS
There was a problem hiding this comment.
Thanks for that and I love easier :) Will get that in for our production build...
Formula/chapel.rb
Outdated
| @@ -16,26 +15,30 @@ class Chapel < Formula | |||
| end | |||
|
|
|||
| depends_on "gmp" | |||
| depends_on "llvm@11" | |||
| depends_on "llvm" | |||
There was a problem hiding this comment.
@tzinsky : Not related to the current CI failures, but I think this should probably be "llvm@13" so that if/when the default llvm becomes llvm@14 in the future, the formula won't break? (since we don't have llvm 14 support yet).
There was a problem hiding this comment.
(Also, I'm noticing that subsequent commands are hard-coded to llvm@13).
There was a problem hiding this comment.
The earlier PR failed audit for this. The error was that the formula should not contain aliases for the most current version. Hence the change to be llvm versus llvm@13
There was a problem hiding this comment.
Oh, interesting!
@SMillerDev : Do you have suggestions for avoiding having this break on the day homebrew's default becomes llvm@14? Since our compiler integrates directly with LLVM, we have to update our compiler sources to become compatible with any new LLVM release (to adjust to the changes to their IR).
There was a problem hiding this comment.
The best way is to make sure the test will fail when run with LLVM 14 libraries.
There was a problem hiding this comment.
@Bo98: I suspect that the existing tests will fail when LLVM 14 is the default. Is the idea then that, when that happens and the failure is triggered, a new formula pinning our formula to llvm@13 would need to be submitted?
If so, would the tripping of that failure be something that would be noticed early and automatically during the LLVM upgrade, or would it require a user to hit it in the field and to let us/someone know? And would submitting the revised formula be our responsibility or the developers doing the LLVM upgrade?
Thanks for improving our understanding here!
There was a problem hiding this comment.
When a formula is updated, all dependents are tested. So when LLVM is updated to 14, the test of chapel will be run as a part of CI.
The LLVM 14 upgrade won't be merged with failing CI so if it's obvious that migrating to LLVM 13 will fix the test then that's exactly what will be done before merging.
There was a problem hiding this comment.
Perfect, thanks for the information and reassurance!
Formula simplification Signed-off-by: Tim Zinsky <tim.zinsky@hpe.com>
Fix for catalina and llvm Signed-off-by: Tim Zinsky <tim.zinsky@hpe.com>
Formula syntax change. Signed-off-by: Tim Zinsky <tim.zinsky@hpe.com>
Audit fixes Signed-off-by: Tim Zinsky <tim.zinsky@hpe.com>
Another catalina llvm fix Signed-off-by: Tim Zinsky <tim.zinsky@hpe.com>
| depends_on "python@3.10" | ||
| on_macos do | ||
| depends_on "llvm" if MacOS.version > :catalina | ||
| depends_on "llvm@11" if MacOS.version <= :catalina |
There was a problem hiding this comment.
That is correct. We are able to build outside of homebrew successfully but the homebrew builds were failing.
There was a problem hiding this comment.
Yes it was the same failure mode as the 3 issues linked below - but for some reason the workaround was not working:
This is a pre-release build and we wish to test this new formula against the Homebrew CI. We would like to have this PR given a
do not mergelabel.brew install --build-from-source <formula>, where<formula>is the name of the formula you're submitting?brew test <formula>, where<formula>is the name of the formula you're submitting?brew audit --strict <formula>(after doingbrew install --build-from-source <formula>)? If this is a new formula, does it passbrew audit --new <formula>?