Thanks to visit codestin.com
Credit goes to github.com

Skip to content

DOC: Explain distribution for f2py with meson-python #25199

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

Open
HaoZeke opened this issue Nov 20, 2023 · 1 comment
Open

DOC: Explain distribution for f2py with meson-python #25199

HaoZeke opened this issue Nov 20, 2023 · 1 comment

Comments

@HaoZeke
Copy link
Member

HaoZeke commented Nov 20, 2023

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.

@jmrohwer
Copy link
Contributor

jmrohwer commented 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 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.F
C
      SUBROUTINE ADD(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
      END
C
      SUBROUTINE HELLO()
C
      PRINT*,"Hello from fortran"
      END
!  File add.pyf
!    -*- f90 -*-
! Note: the context of this file is case sensitive.

python module add ! in 
    interface  ! in :add
        subroutine add(a,b,c) ! in :add:add.f
            double precision intent(in) :: a
            double precision intent(in) :: b
            double precision intent(out) :: c
        end subroutine 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:

    numpy/numpy/f2py/f2py2e.py

    Lines 682 to 688 in 7a9ab61

    if backend_key == 'meson':
    outmess('Using meson backend\nWill pass --lower to f2py\nSee https://numpy.org/doc/stable/f2py/buildtools/meson.html\n')
    f2py_flags.append('--lower')
    if pyf_files:
    run_main(f" {' '.join(f2py_flags)} {' '.join(pyf_files)}".split())
    else:
    run_main(f" {' '.join(f2py_flags)} -m {modulename} {' '.join(sources)}".split())

    The check would have to be moved out of the run_compile() method into a separate method, and called from main() appropriately:

    numpy/numpy/f2py/f2py2e.py

    Lines 737 to 740 in 7a9ab61

    if '-c' in sys.argv[1:]:
    run_compile()
    else:
    run_main(sys.argv[1:])

I would appreciate comments on how to deal with this and can submit a PR for either scenario.

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

No branches or pull requests

3 participants