8000 FindF2PY: ensure generic f2py executable is looked up first by smiet · Pull Request #1111 · scikit-build/scikit-build · GitHub
[go: up one dir, main page]

Skip to content

Conversation

smiet
Copy link
@smiet smiet commented Aug 6, 2024

In issue #449 a change was made to the resolution of F2py to support python2 builds and prefer the versioned f2pyx over an unversioned.

find_program(F2PY_EXECUTABLE NAMES f2py f2py${PYTHON_VERSION_MAJOR})

This made sense at the time, but with the now final deprecation of python2, and numpy dropping f2py3 in version 1.26 this change has come to bite us.

Now if using a virtual environment with a version of numpy>1.26, but an OS/system that has a python with numpy<1.26, cmake will prefer the f2py3 of the OS, leading to hard-to-diagnose problems.

With numpy>=2.0 C-API changes, code compiled with the systems f2py will not run in the environment.

@sdrave
Copy link
sdrave commented Aug 8, 2024

We have been affected by this issue as well. Trying to pip install python-control/slycot in a venv will fail on any machine with a globally installed numpy<2. pip will pull numpy 2 as a build dependency and use its headers, but cmake will select the system f2py to generate the bindings.

@smiet
Copy link
Author
smiet commented Aug 8, 2024

A quick and dirty workaround is to add a symlink called f2py3 in your virtual environment:
$ ln -s /path/to/venv/bin/f2py /path/to/venv/bin/f2py3
Then CMake will look there first and not find the system's executable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0