Updating package for SOLLVE#12607
Conversation
adamjstewart
left a comment
There was a problem hiding this comment.
I assume this package is largely the same as the LLVM package in Spack? You can actually subclass that package if you want so there isn't so much code duplication.
5def1dd to
ab1f4ba
Compare
SOLLVE goes in depth on certain features for exascale. LLVM development is rapid. SOLLVE shouldn’t and doesn’t need to keep up with all the changes in LLVM, so we think it’s best that SOLLVE shouldn't be a subclass of LLVM. |
ab1f4ba to
9434fa1
Compare
|
Sorry for the long delay to clean up this PR. @adamjstewart Could you please review it again? I believe we fixed the issues you pointed out. About the subclass, in addition to @vlkale's comments, I think now the SOLLVE's code is not simply a duplication of LLVM. (Actually I tried to use LLVM as a subclass of SOLLVE, but it was quite hard to use their functions and class member variables). I believe making this package independent of the LLVM package is cleaner and simpler (and less troublesome to maintain since the LLVM package should be updated much more frequently). |
|
Hi @adamjstewart, Can you look at this pull request again when you have a chance? @shintaro-iwasaki and I have worked on this package, and we think that it's in a reasonable state to be merged. Vivek |
adamjstewart
left a comment
There was a problem hiding this comment.
Sorry it took me so long to review! Just a few recommended changes to make.
Co-authored-by: Vivek Kale <[email protected]>
Copied from llvm/package.py.
9434fa1 to
3eb1a02
Compare
|
Thanks for reviewing this! I rebased the whole branch to the latest The second commit is to reflect your suggestions. |
adamjstewart
left a comment
There was a problem hiding this comment.
You have a lot of variants that add flags to disable things. It would be better to always be explicit and say:
if '+foo' in spec:
args.append('-DENABLE_FOO=ON')
else:
args.append('-DENABLE_FOO=OFF')CMake likes to switch the default based on what it can find on your OS, leading to non-deterministic builds if you aren't explicit like this.
| """ | ||
|
|
||
| homepage = 'https://www.bnl.gov/compsci/projects/SOLLVE/' | ||
| url = "https://github.com/SOLLVE" |
There was a problem hiding this comment.
You can get rid of this url since it isn't used. You can actually move the git up here like so:
| url = "https://github.com/SOLLVE" | |
| git = "https://github.com/SOLLVE/llvm.git" |
Then it won't need to be specified in every version() directive below.
There was a problem hiding this comment.
Thanks! You're right. I updated urlt and git in version() as you suggested.
|
Thanks for revising the file for SOLLVE’s Spack package given Adam’s suggestions from today. Hi @adamjstewart, I agree with all of Shintaro’s changes. Your suggestion to always be explicit for disabling makes sense and I agree with it. Thanks for pointing out Cmake’s behavior. (@shintaro-iwasaki: can you quickly search for cases where we are disabling things in our python file for Spack package of SOLLVE, and fix them according to Adam’s suggestion and corresponding example? Let me know if you need my help with this and I’ll get on it as soon as possible). Vivek |
- url -> git - remove git in version() - explicit cmake options in else clauses - add newlines for better readability
|
Thanks for reviewing the PR! |
adamjstewart
left a comment
There was a problem hiding this comment.
Looks good to me. If there are any additional changes required they can happen in another PR.
|
Referencing #14188 for Pull Request of Release of SOLLVE’s Spack package. |
I'm creating a pull request for a Spack package for the SOLLVE project, which will be built based on the Spack package for the LLVM project. The Spack package for the SOLLVE project would be used by application programmers of OpenMP applications, especially ECP OpenMP applications, to experiment with the latest features in SOLLVE project's software technologies.