[Numpy-discussion] numpy build system questions for use in another project (fwrap)

Kurt Smith kwmsmith@gmail....
Sat Apr 10 21:21:03 CDT 2010


On Sat, Apr 10, 2010 at 9:53 AM, Dag Sverre Seljebotn
<dagss@student.matnat.uio.no> wrote:
> Kurt Smith wrote:
>> On Fri, Apr 9, 2010 at 2:25 AM, David <david@silveregg.co.jp> wrote:
>>> On 04/07/2010 11:52 AM, Kurt Smith wrote:

>> Fortran's .mod files are essentially compiler-generated header files;
>> fwrap needs to use these 'headers' to get type information so it can
>> figure out how the C types and Fortran types match up.  Fwrap then
>> generates the config files with this information and compiles the
>> wrappers with the other source files.
>
> I hope there will at least be an option to supply mod files instead of
> using this mechanism. For "wrapper" projects which already (presumably)
> has a build system for the Fortran code set up it seems more reasonable
> to me to just refer to the output of the existing build.

Yes -- I've been thinking about this usecase recently, and I was
thinking along the same lines.  Fwrap shouldn't have to have a fully
general Fortran build system, that obviously isn't its intended
purpose.  (Build systems for mixed Fortran/C/C++/Whatever are becoming
quite an albatross[0], IMHO, and fwrap would do well to avoid the
whole issue).  I've been assuming up until now that since f2py takes
care of it, so should fwrap, but that's foolish.  The scipy sources
that f2py wraps are all fairly simple, and they're F77 source, which
have no concept of interfaces, etc.  F9X source is a different beast.

I'm realizing the many conflicting usecases that are out there, and
the impossibility for fwrap to handle them all well.  The simple cases
(you mention below) with a few fortran source files are fine, but for
a big project with a complicated & long build process, it would be
foolish for fwrap to try and become a fully general Fortran build
system in addition to its intended purpose.

It isn't always clear what compiler flags one needs to use to ensure
that the fortran code is compiled suitably for a Python extension
module.

Here's what I'll probably do:

Python has a 'python-config' command that indicates the different
flags, include and link libraries to use to compile extension modules.
 Fwrap could do something similar, and the user is responsible for
supplying the compiled .o and .mod files, using the configuration
flags supplied by fwrap for compilation.

So you could do something like the following to get the compiler flags:

$ fwrap --get-cflags --fcompiler=intelem

And it would spit out the flags necessary to include when compiling
the fortran source files.

The user is responsible for handing off the .o and .mod files to
fwrap, and fwrap then does the rest.

This is good -- I think we're converging on a solution.  And it keeps
fwrap focused on what it's supposed to do.

>
> In particular I don't like the situation today with Python wrappers
> around C code, where the C code files are often copied into the Python
> wrapper project. I hope the same won't happen with fwrap, i.e. that
> people don't copy the Fortran sources to the fwrap wrapper just to make
> things easy to build (but end up forking the project and not keep it up
> to date).

No -- I'll do everything in my power to keep anything like this from
being necessary :-)

Thanks for the input.

Kurt

[0] http://en.wikipedia.org/wiki/Albatross_%28metaphor%29

>
> Of course, if one is not wrapping an existing module but rather
> developing an application with fwrap then the situation is different, I
> suppose.
>
> --
> Dag Sverre
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>


More information about the NumPy-Discussion mailing list