[Distutils] FORTRAN extension modules

[John J. Lee]

On Sun, 14 Jan 2001, John J. Lee wrote:

> Has anyone added any FORTRAN support since the version of Distutils that
> came with python 2.0?  I tried compiling Multipack with Distutils (after
> setting up the source with modified versions of the Makefile and
> setmodules.py from the Multipack distribution) by subclassing from
> UnixCCompiler, but of course that only works if you do it in two steps:
>
> ./setup.py build_clib -c unixf
>
> ./setup.py build_ext

Actually of course with g77 (FORTRAN front-end to gcc) it will work with
just

./setup.py build -cunixf

because g77 will happily do C too.  Presumably this doesn't apply to many
(any?) other compilers, though.

Oddly though, after you've built your extensions and libraries, this
*doesn't* work:

./setup.py install

as it will default to the compiler named 'unix' (ie. unixccompiler.py),
see that things aren't up to date from its point of view (not sure exactly
why, but presumably because the compiler has changed), and try to compile
the FORTRAN with a plain 'gcc -c' command which fails, of course.  You
can't do this:

./setup.py install -cunixf

because there is no -c option for the install command.

> where unixf is my added FORTRAN compiler.  I suppose the right thing would
> be to put it in CCompiler itself, so that all its subclasses would be
> capable of compiling FORTRAN too (with appropriate modifications)?

For the case of gcc, I should have been able to do this by just telling
Dustutils to substitute g77 for gcc, add a new list of file prefixes for
source (".f" etc), and not modify the source at all - shouldn't this be
possible via the command line?  I know it is the intention eventually to
drive that sort of thing from an autoconf-style thing, but in the mean
time, it would seem to be useful to be able to change at least the
executable names via the command line / config file - or have I missed the
option that does this?

> I suppose the same would be true of, eg Pascal too.  Maybe the class needs
> renaming too...
[...]


John