You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
DOC: Explain distribution for f2py with meson-python #25199
Some older issues (e.g. #19441, #22211 (comment)) and parts of the documentation very briefly cover distribution of extensions with F2PY sources. It seems (anecdotally) that telling people to go look at SciPy hasn't been super helpful so, a proper documentation section would be nice.
I'm commenting here but happy to open a new issue/PR, depending on how the decision is to go forward.
When building Fortran extension modules, one might only want to use f2py to generate the C sources (see also #22211 (comment)) but do the compiling with the build system. In addition, custom *.pyf signature files can be used to only expose the routines required. Consider the following Fortran file defining two subroutines ADD and HELLO, of which we only want to expose ADD (see the *.pyf):
C FILE ADD.FCSUBROUTINEADD(A,B,C)
C
CF2PY INTENT(OUT) :: C
CF2PY INTENT(IN) :: A
CF2PY INTENT(IN) :: B
CF2PY DOUBLE PRECISION:: A
CF2PY DOUBLE PRECISION:: B
CF2PY DOUBLE PRECISION:: C
DOUBLE PRECISION A
DOUBLE PRECISION B
DOUBLE PRECISION C
C = A + B
ENDCSUBROUTINEHELLO()
CPRINT*,"Hello from fortran"END
! File add.pyf
! -*- f90 -*-
! Note: the context of this file is case sensitive.
python module add ! in
interface ! in :add
subroutineadd(a,b,c) ! in :add:add.f
double precisionintent(in) :: a
double precisionintent(in) :: b
double precisionintent(out) :: c
endsubroutine add
end interface
end python module add
! This file was auto-generated with f2py (version:1.26.1).
! See:
! https://web.archive.org/web/20140822061353/http://cens.ioc.ee/projects/f2py2e
Generating the C sources as follows works as expected:
f2py add.pyf
However, generating the C sources as follows:
f2py -m add add.pyf add.f --lower
also adds the interface to hello() to addmodule.c.
I see this being fixed one of two ways:
properly explain this usage and the caveats in the documentation
check for the presence of *.pyf file(s) and deal with this transparently, similar to f2py -c.
See here in the run_compile() method:
Activity
jmrohwer commentedon Nov 28, 2023
I'm commenting here but happy to open a new issue/PR, depending on how the decision is to go forward.
When building Fortran extension modules, one might only want to use
f2pyto generate the C sources (see also #22211 (comment)) but do the compiling with the build system. In addition, custom*.pyfsignature files can be used to only expose the routines required. Consider the following Fortran file defining two subroutinesADDandHELLO, of which we only want to exposeADD(see the *.pyf):Generating the C sources as follows works as expected:
However, generating the C sources as follows:
also adds the interface to
hello()toaddmodule.c.I see this being fixed one of two ways:
f2py -c.See here in the
run_compile()method:numpy/numpy/f2py/f2py2e.py
Lines 682 to 688 in 7a9ab61
The check would have to be moved out of the
run_compile()method into a separate method, and called frommain()appropriately:numpy/numpy/f2py/f2py2e.py
Lines 737 to 740 in 7a9ab61
I would appreciate comments on how to deal with this and can submit a PR for either scenario.
DOC: Add f2py distribution guide for meson-python
DOC: Add f2py distribution guide for meson-python
DOC: Add f2py distribution guide for meson-python
DOC: Add f2py distribution guide for meson-python
DOC: Add f2py distribution guide for meson-python
DOC: Add f2py distribution guide for meson-python
DOC: Add f2py distribution guide for meson-python
DOC: Add f2py distribution guide for meson-python
DOC: Add f2py distribution guide for meson-python