openmpi: get rid of implicit system dependencies#16758
openmpi: get rid of implicit system dependencies#16758adamjstewart merged 4 commits intospack:developfrom
Conversation
10da26d to
0cd82b8
Compare
0cd82b8 to
72bcb2f
Compare
adamjstewart
left a comment
There was a problem hiding this comment.
This looks good to me, I like the idea of explicitly listing external dependencies in packages.yaml.
@hppritcha can you review this? @alalazo may also be interested
|
👍 for the Open MPI part. We really should also remove all these ancient versions (anything older than the 2 series). We (Open MPI devel team) never even check now if these versions can compile on, say rhel8. |
I started an issue to discuss this in #15896 |
6aa886f to
f2216d7
Compare
|
@skosukhin One of the cluster's spack toolchains I maintain uses an installation of Torque rather than "pbspro", which died in concretization with its limitation of Python 2. A little history shows PBS to have forked into OpenPBS, PBSPro, and Torque. Do we need to add a virtual package "pbs" to allow the use of all three? For the moment, I have worked around the issue by disabling the python requirement in the |
Currently,
openmpihas there implicit dependencies, which it tries to find in the system directories (see_verbs_dir(),_mxm_dir(), and_tm_dir()). This PR makes those dependencies explicit and the users now can specify custom prefixes to those libraries inpackages.yaml._verbs_dir()is removed. Instead,openmpidepends onrdma-core:rdma-coreas an external package inpackages.yaml:_mxm_dir()is removed. Instead,openmpidepends on a new dummy packagemxm:mxmcan't be installed with Spack (at least for now) and needs to be specified inpackages.yaml:_tm_dir()is removed. Instead,openmpidepends on a new packagepbsproopenpbs:pbsproopenpbscan be installed with Spack. It depends on a new packagelibicaland a new virtual packagesendmailprovided be a new real packagessmtp. Althoughpbsproopenpbscan be installed with Spack, I can't guarantee that it will be usable: I don't have experience with the package to test it properly. Additionally, its scripts do not seem to properly account for the case when the package is installed to a non-system directory. Therefore, I would recommend the users to specify it as an external package too:lsfis updated to allow for: