Improve external builds/update polytope#337
Conversation
…cretizes by default, added cmake logic to use find_package on polytope, updated polytoper version, added check for spheralutils python version, overhaul docs, changed collections module to collections.abc
…system library to ignore warnings during the build
…interactions through spack
…pec to environments, removed renaming export of polytope target
…dd rztrona to spheral_ats
…s, added SpheralConfig timer flag, only turn off mpi finalize if timers are enabled for the build
…hange SpheralConfigs, turn off mpi4py finalize if LEOS is enabled
… packages for spack to search for in the tpl-manager
…they cause issues with newer python versions
…t set mpi install that is found as the provider instead of modifying the spec
…r sundials with openmpi, reverted system package docs
…and caliper specs, removed caliper package.py, removed latex from system installs for external users
jmikeowen
left a comment
jmikeowen
left a comment
There was a problem hiding this comment.
Looks good to me -- nice job updating the docs!
| @@ -1,6 +1,6 @@ | |||
| # CMakeLists to build the Spheral library. | |||
|
|
|||
| cmake_minimum_required(VERSION 3.14) | |||
There was a problem hiding this comment.
Is there an explicit cmake 3.21 feature we need to bump this?
There was a problem hiding this comment.
You'll need CMake 3.21 to work with Hip and the latest BLT release.
There was a problem hiding this comment.
Probably but this PR isn't bringing in any HIP compiled code, we tried bringing this version up from 3.14 to 3.18 a while ago and had issues with BLT and CUDA. The consensus after speaking with the BLT folks was to revert back to 3.14 until we had a necessity to push the version. When HIP executing changes get pushed to Spheral is probably when we will revisit our minimum version constraint.
There was a problem hiding this comment.
I tried this out today on a fresh Fedora 42 install. I was unable to install the Spheral dependencies through spack:
- Fedora 42 is on Python 3.13. Our current version of Spack fails to bootstrap clingo. (Since this isn't necessarily our fault I manually built and installed Python 3.11 to get past this).
dnfon Fedora seems to install packages in 3 places e.g. w/ cmake/bin/cmake,/usr/bin/cmakeand/usr/sbin/cmake. Spack successfully finds all 3, however the paths it stores in theyamlfile are (/bin,/usr,/usr/sbin). During the builds spack tries to build with the path/usr/sbin/bin/cmakewhich does not exist and causes all packages that build with cmake to fail.- spack isn't picking up some packages I would expect
ncurses,curl,wget,zlibmany of which are later failing to build with thegcc@15.1.1for Fedora 42. When I explicitly spack find some of these it is able to pick them up.
This is a shame because it seems most of these issues are out of our control and are problems with spack / it's package recipes.
There are a few improvements that I think we can address in the near future:
- When building externally it's not always clear which packages spack has found and exactly where it is pointing to them. It would be nice to have some output communicating this.
- I think instead of letting spack implicitly find everything on the system we should define a set of packages we always expect to be on the system like
ncursesand explicitly search for them (like we do for python perkl and mpi right now), especially since we have users install some of those packages with their respective package managers.
This PR is a step in the right direction for external users but we aren't there yet unfortunately. I don't think we need to address any of the above right now. We should update to the spack 1.0 and see where things settle, but we will probably need to work with the spack team to resolve some of the above.
…LNL/spheral into bugfix/improve_external_builds
4 participants
Summary
ToDo :
RELEASE_NOTES.mdwith notable changes.