-
-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gromacs: don't force build with gcc #129648
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -25,7 +25,10 @@ class Gromacs < Formula | |
depends_on "gcc" # for OpenMP | ||
depends_on "openblas" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Note that OpenBLAS uses There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm, not sure what do about this.... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
So is it appropriate to just replace Or is it reasonable to entirely leave out the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I simply don't think we can build that with libomp There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To be clearer: I think the issue is in the (proposed) votca formula and should be fixed there. We don't want to introduce this mixed-OpenMP linkage. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
What is the actual problem with that? I have seen openblas being built with clang using spack.io before. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Again I am not sure about this either, we build VOTCA on large variety different compiler and library combination without problems. And I of course tried to restrict votca to gcc as well, which led to this error: #129512 (comment) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
If I believe: |
||
|
||
fails_with :clang | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would be happy to test again, compiling with clang. It seems like it would be nice to remove this broad clang-avoidance. But what is the mechanism for choosing compiler toolchain for either There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. update:
|
||
on_macos do | ||
depends_on "libomp" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This change may have succeeded in establishing a package dependency, but without additional CMake arguments, the build system configuration is still free to find |
||
end | ||
|
||
fails_with gcc: "5" | ||
fails_with gcc: "6" | ||
|
||
|
@@ -35,24 +38,20 @@ def install | |
"CMAKE_INSTALL_DATADIR" | ||
|
||
# Avoid superenv shim reference | ||
gcc = Formula["gcc"] | ||
cc = gcc.opt_bin/"gcc-#{gcc.any_installed_version.major}" | ||
cxx = gcc.opt_bin/"g++-#{gcc.any_installed_version.major}" | ||
inreplace "src/gromacs/gromacs-hints.in.cmake" do |s| | ||
s.gsub! "@CMAKE_LINKER@", "/usr/bin/ld" | ||
s.gsub! "@CMAKE_C_COMPILER@", cc | ||
s.gsub! "@CMAKE_CXX_COMPILER@", cxx | ||
s.gsub! "@CMAKE_C_COMPILER@", ENV.cc | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Where does |
||
s.gsub! "@CMAKE_CXX_COMPILER@", ENV.cxx | ||
end | ||
|
||
inreplace "src/buildinfo.h.cmakein" do |s| | ||
s.gsub! "@BUILD_C_COMPILER@", cc | ||
s.gsub! "@BUILD_CXX_COMPILER@", cxx | ||
s.gsub! "@BUILD_C_COMPILER@", ENV.cc | ||
s.gsub! "@BUILD_CXX_COMPILER@", ENV.cxx | ||
end | ||
|
||
inreplace "src/gromacs/gromacs-config.cmake.cmakein", "@GROMACS_CXX_COMPILER@", cxx | ||
inreplace "src/gromacs/gromacs-config.cmake.cmakein", "@GROMACS_CXX_COMPILER@", ENV.cxx | ||
|
||
args = %W[ | ||
-DGROMACS_CXX_COMPILER=#{cxx} | ||
-DGMX_VERSION_STRING_OF_FORK=#{tap.user} | ||
-DGMX_INSTALL_LEGACY_API=ON | ||
] | ||
|
@@ -76,6 +75,6 @@ def caveats | |
end | ||
|
||
test do | ||
system "#{bin}/gmx", "help" | ||
system "#{bin}/gmx", "-version" | ||
end | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need
depends_on "gcc" # for OpenMP
or is it even the appropriate way to ensure anomp
facility if we always depend onopenblas
? I mean, is theomp
dependence ofopenblas
sufficiently transitive?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We prefer dependencies to be explicit than transitive, when there is a direct dependency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good. In order to be both explicit and correct, how would
gromacs.rb
reference the (brew) package dependency to get appropriate CMake hints? (I think the only available CMake input variable isOpenMP_CXX_INCLUDE_DIR
, since the details are normally so compiler-specific.)It seems like we might need the choice of
libomp
vs.libgomp
to be coupled to the choice ofclang
vs.gcc
?Or is there a way to inspect the
openblas
dependency and just use whatever it used?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no choice to be had: formulas don't really have options, and binaries shipped are built on our CI machines.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you are saying
openblas
, so it can and should encode decisions needed to build compatibly, per the openblas formulalibgomp
Are all three of those points correct?
I'm particularly unclear on that last one, since it would seem to invalidate the whole premise of this pull request (which has not yet been outright rejected). It seems like any one of those points, though, would invalidate much of this change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes (except there is no
libgomp
, it is a part ofgcc
). I have not outright closed the PR because I wanted to see if any other maintainer felt differently about it, but it seems not, so I'll close it now.