-
Notifications
You must be signed in to change notification settings - Fork 44
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
Reduce dependency on hand-built packages #705
Comments
I agree with the intention of this issue. But let me note that |
Noted. I've had some success with building ecflow with intel under spack (though in the distant past I've run into the issue you describe). I'll test it out on various systems when I have time. |
Great news! Not sure we can make it part of this release, given the short time we have and all the testing it needs, but even if not then definitely for the next one. That would be hugely helpful to have going forward. Thanks for looking into this. |
Quick update-- I've reproduced what I believe is the same issue with cereal/boost. The problem occurs not in running ecflow_server, but in running any ecflow_client command to communicate with it. I'll dig a little more, but for now the answer might be either to only use boost%gcc, or to not build ecflow with intel, as it doesn't look like the issue will be resolved (in one place, it appeared that it came down to interpretations of code standards, so intel classic may not ever support the relevant feature). |
Are there any updates on this issue; how should we move forward? It seems there's also tension here with the notion that we can use platform libraries to make builds more rapid and smaller, is there any consensus on the better approach? |
mysql is no longer an issue, since the new R2D2 doesn't require it (but we need to remove it from the dependency on mysql and mysql-connector from the spack virtual packages/environments). The remaining one is ecflow, which can't be fixed with Intel classic. Once we update all site configs to use intel oneapi (icx, icpx) then this issue can be closed. |
Is your feature request related to a problem? Please describe.
The goal of spack-stack is to avoid the bad old days of manually configured package installations. Across the platforms supported by spack-stack, there are non-spack installations of packages including python, ecflow, openmpi, and mysql, which are relied on by spack-stack packages and/or the applications we support. These outside packages add complexity and risk (e.g., ufs-community/ufs-weather-model#1707 (comment)), and the goal of spack-stack is to have a single, self-consistently built software stack.
Describe the solution you'd like
Let's reduce the dependence on external packages as much as possible. MySQL is probably the trickiest of them, and I don't know the full extent of the story behind having separate python installations, but ecflow and openmpi for example should not be difficult to incorporate into the unified environment.
The text was updated successfully, but these errors were encountered: