[Numpy-discussion] f2py: sharing F90 module data between modules

[Pearu Peterson]

On Thu, February 14, 2008 8:24 am, Garry Willgoose wrote:
> Thanks for that. The docs suggest library dl is Unix only. Does that
> mean this solution will not work on Windows? Windows is on my
> implementation roadmap but I'm not quite there yet to test it.

I have no idea whether it will work on Windows or not. I would try
though as there seems to be other ways than dl to find the needed
flags as Lisandro pointed out.

> I guess I am now thinking maybe I can assemble (using f2py) an
> (aggregated) shared library on the fly from the individual module
> shared libraries when I open my modelling environment. I could check
> the aggregated library mod dates against all the .so files of the
> components and only rebuild the aggregated library if there was a
> newer component than the aggregated library. That appears to work
> (and is fast) except for one behaviour of f2py. If I give f2py a list
> of files that are ALL .so (i.e. no fortran files) then f2py quits
> without actually doing anything, even if all the component shared
> libraries all have perfectly fine pythons interfaces from previous
> f2py builds. I can give it a trivial fortran file (module .. end
> module) and it works fine.

Note that f2py job is not really perform linking tasks. It is
a useful feature that simplifies creating extensions modules,
but please, don't complain if it cannot be used as a general linker:)

> Why is that problem? I can envisage a user that just wants to use the
> environment without writing any additional fortran modules (and thus
> may not even have an installed fortran compiler) and if they screw up
> mod dates on the files (by say a ftp from one machine to another ...
> for instance on our cluster the compiler is only installed on one
> machine and only binaries are moved around the cluster) then the
> environment might want to reassemble (with f2py) the aggregated
> library because it (erroneously) thinks there is a newer component
> shared library. This will fail because f2py quits when asked to
> process ONLY .so files. If I have a trivial fortran file to force
> f2py then this forces users to have a fortran compiler on their
> machine, even if they do not want to actually compile a new fortran
> module component, simply because f2py will not operate unless it is
> offered at least one fortran file.

This is not a typical task for f2py. f2py is not a general purpose
linker. It's amazing that f2py could even be used for such a task,
so I don't think that the above demonstrates any bug of f2py.

However, if you are worried about whether users have fortran compilers
installed then can you assume that they have a C compiler installed?
If so, then instead of trivial Fortran file try using the following
trivial .pyf file:

python module dummy
  interface
    subroutine dummyfunc()
      fortranname
      callstatement ;
    end subroutine dummyfunc
  end interface
end python module dummy

that should force f2py to build a shared library dummy.so
with no Fortran dependencies.

> Does this make sense or am I just being thick about this? Is there a
> way of making f2py merge a number of existing shared libraries into a
> single library without having to compile any fortran. I guess I could
> just invoke the linker directly in the case where there are no
> fortran files to compile but is nice being able to use distutils to
> get away from platform dependencies.

Hopefully the hint above works for you.

Pearu