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

[Dag Sverre Seljebotn]

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


-- 
Dag Sverre