Skip to content

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

Closed

Description

@HaoZeke

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.

Activity

  1. jmrohwer commented on Nov 28, 2023

    @jmrohwer
    Contributor

    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.

  2. added 9 commits that reference this issue on Mar 8, 2026
    58011f7
    5c2cd66
    2186197
    7d318ca
    38fb8dd
    a3f89d8
    cde5986
    946ce6c
    97c2ec9
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions