Closed will-saunders-ukaea closed 2 years ago
Does this still respect the ^python
argument for building NekPy?
I've amended the boost requirements to include boost-numpy when +python (fixes dependency issues on my machine). I think fixing the install such that "from NekPy import *" works out of the box is an issue for a separate PR (it works if ran in the build_tree directory)
Edit: amended this PR to include setting PYTHONPATH such that importing NekPy works (assuming the correct python)
Avoids users having to use "--keep-stage" to avoid files being removed that are pointed to by nektar++ cmake files (and not copied to output dir).
Are you referring to the BLAS/LAPACK binaries which it builds? This can be better solved by modifying he CMake arguments to ensure it will find the ones already installed by Spack and doesn't need to build its own, inefficient ones. This will be part of a pull request I will be raising imminently.
Yes - these libraries were one of the issues. I think we also were having issues with how the Python (NekPy) was being (or was not being) installed. Hopefully this copied build directory approach is a temporary fix until cmake changes are made upstream.
I found I had to install specific python packages e.g. numba during the spack install step in order to have access to the right versions after the fact.
I found I had to install specific python packages e.g. numba during the spack install step in order to have access to the right versions after the fact.
Not sure I follow what you're saying. Do you mean that you had to modify the package file to install some specific packages during the build step? What do you mean by "the right version"? Of which package? What is "the right version"?
I had to find the version of pyhton that spack installed in the spack path and install things there. Only possible by having an eagle eye on the build process
On Fri, 16 Sept 2022, 13:29 Chris MacMackin, @.***> wrote:
I found I had to install specific python packages e.g. numba during the spack install step in order to have access to the right versions after the fact.
Not sure I follow what you're saying. Do you mean that you had to modify the package file to install some specific packages during the build step? What do you mean by "the right version"? Of which package? What is "the right version"?
— Reply to this email directly, view it on GitHub https://github.com/ExCALIBUR-NEPTUNE/NESO-Spack/pull/1#issuecomment-1249304767, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADWNA6XZXGN34KZFBEIRPXDV6RR37ANCNFSM6AAAAAAQIS4I7U . You are receiving this because you modified the open/close state.Message ID: @.***>
Builds nektar++ in the spack prefix directory for the stage. Avoids users having to use "--keep-stage" to avoid files being removed that are pointed to by nektar++ cmake files (and not copied to output dir).