On Sat, Apr 10, 2010 at 9:53 AM, Dag Sverre Seljebotn <da...@student.matnat.uio.no> wrote: > Kurt Smith wrote: >> On Fri, Apr 9, 2010 at 2:25 AM, David <da...@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 > _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
