[Numpy-discussion] numpy build system questions for use in another project (fwrap)
Dag Sverre Seljebotn
Sun Apr 11 12:54:04 CDT 2010
Kurt Smith wrote:
> On Sat, Apr 10, 2010 at 9:53 AM, Dag Sverre Seljebotn
> <firstname.lastname@example.org> wrote:
>> Kurt Smith wrote:
>>> On Fri, Apr 9, 2010 at 2:25 AM, David <email@example.com> 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, 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
> 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
a) Use the same compiler for both the Fortran project and the fwrap
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
>> 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.
>  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
>> Dag Sverre
>> NumPy-Discussion mailing list
> NumPy-Discussion mailing list
More information about the NumPy-Discussion