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

[Dag Sverre Seljebotn]

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:
>>> Briefly, I'm encountering difficulties getting things working in numpy
>>> distutils for fwrap's build system.
>>>
>>> Here are the steps I want the build system to accomplish:
>>>
>>> 1) Compile a directory of Fortran 90 source code -- this works.
>>>      - The .mod files generated by this compilation step are put in the
>>> build directory.
>> This is difficult - fortran modules are a PITA from a build perspective.
>> Many compilers don't seem to have a way to control exactly where to put
>> the generated .mod, so the only way I am aware of to control this is to
>> cwd the process into the build directory...
> 
>>From what I can tell, numpy's distutils already takes care of putting
> the .mod files in the build directory (at least for gfortran and
> ifort) by manually moving them there -- see
> numpy.distutils.command.build_ext.build_ext.build_extension, after the
> line "if fmodule_source".  This is fine for my purposes.  All I need
> is the project's .mod files put in one place before the next step.
> 
>> This was also a problem when I worked on fortran support for waf (see
>> http://groups.google.com/group/waf-users/browse_thread/thread/889e2a5e5256e420/84ee939e93c9e30f?lnk=gst&q=fortran+modules#84ee939e93c9e30f
>> )
> 
> Yes, I saw that thread and it dissuaded me from pursuing waf for now.
> I'd like to take a stab at it sometime down the road, though.
> 
>>> My problem is in instantiating numpy.distutils.config such that it is
>>> appropriately configured with command line flags.
>>>
>>> I've tried the following with no success:
>>>
>>> ('self' is a build_ext instance)
>>> cfg = self.distribution.get_command_obj('config')
>>> cfg.initialize_options()
>>> cfg.finalize_options()  # doesn't do what I hoped it would do.
>>>
>>> This creates a config object, but it doesn't use the command line
>>> flags (e.g. --fcompiler=gfortran doesn't affect the fortran compiler
>>> used).
>> Why don't you do the testing in config ? That's how things are done
> 
> 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.

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).

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