Kurt Smith wrote: > 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.
Hmm. Would --get-cflags ever return anything but (the equivalent of) -fPIC? For C source which includes "Python.h" there are more flags (-fno-strict-aliasing for instance) because Python.h requires it. BUT, note that this is only for "Python.h"-including C source. For just linking in C source without a Python.h dependency, the compiler flags don't matter at all, just as long as one uses -fPIC (IIUC). Fortran code is also in this latter category, so I wonder whether what you mention above is really necesarry. To me it seems like one can just document: a) Use the same compiler for both the Fortran project and the fwrap wrapper. b) Use -fPIC. c) Feed the build system of the fwrap wrapper the path to the mod 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. Yes, apart from my nitpicking questions above, this sounds good to me at least. Dag Sverre > >> 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 -- Dag Sverre _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
