Move to toml #226
Move to toml #226
Conversation
on my system does not compile because usual compiler resolves paths to blas and lapack with library paths with strings '-pthread' instead of full file path. This then borks the f2py compilation that can only deal with filepaths. Not sure how to fix.
I cannot make them work with toml-based install.
to avoid common pitfall and show users some common variables.
|
Can you ensure that this is buildable on different machines? Please check on a few machines and let me know how it goes. Also, the cmake modules are not required. |
|
Are you sure scikit-build-core works with Fortran? Can you please test by not installing scikit-build? |
…r than source files
|
I tested on python3.12 and 3.13 in a docker container, and this build does not work there. I don't know how to fix. Please help. Why? : these python versions force the use of meson backend for the f2py compilation. Meson cannot build in the same directory as the source files (tries to copy them before build). Traceback (most recent call last):
File "<python-input-0>", line 1, in <module>
import spec.spec_f90wrapped as spec
File "/usr/local/lib/python3.13/site-packages/spec/spec_f90wrapped.py", line 2, in <module>
import _spec_f90wrapped
ImportError: /usr/local/lib/python3.13/site-packages/spec/_spec_f90wrapped.cpython-313-x86_64-linux-gnu.so: undefined symbol: __allglobal_MOD_dtcNot sure if it is generically due to the switch to meson or because of the change of build directory. |
|
OK. I'll take a look next week. |
the distutils based install was deprecated, and installing with
python setup.pyis no longer the way.Here is my first attempt at moving to pyproject.toml (With some help from AI).
Did not find a neat way to implement the cmake_machines.json functionality with this type of install.
One can use environment variables to control the install, but there might be a better way... let me think this through, but also see if the tests run well.
Note: The generation of the f2py compile command is still a sore spot, CMake loves to resolve libraries with a '-lpthread' or similar string instead of a full path to a shared object (sometimes a combination!). This then gives a hard-to-diagnose error in the final step of linking the python wrappers.