[Distutils] Compiler abstractiom model

[Greg Ward]

Quoth Paul F. Dubois, on 30 March 1999:
> Just to chime in about the unmentionable, I have a tool for connecting
> Fortran and Python (as do others; mine isn't ready for the light of day yet)
> and unfortunately the existing Setup scheme makes me compile my Fortran
> separately in a library. I don't have any way to piggyback on what Python
> has learned about the platform. This is too bad. I am sure it isn't the
> Python community's job to solve the Fortran 90 make problem but there are
> days when I dream about it.
> 
> The "right" object-oriented approach should allow some way to extend the
> system, e.g. adding suffices or file names together with info about how to
> compile them.

The way I see Distutils being extended is by people writing new command
classes.  Let's say LLNL wants to distribute a Python module with a
(shudder) FORTRAN back-end, and Distutils doesn't support FORTRAN.
(Sorry, not a lot of call for it.)  The general idea, which I have not
fully thought through, is that you would write a "BuildFortran" class,
and include it with your code -- right there in setup.py if it's not too 
big.  Then, your setup.py would look something like this:

    class BuildFortran:
        # ...

    setup (name = "llnl-fortran-module",
           version = "1.0",
           description = "Front end to some crufty FORTRAN code",

           cmdclass = {build_fortran: BuildFortran},

           py_modules = ['mod1', 'mod2'],
           fortran_extensions = ['fext1', 'fext2'])

The part that I haven't really thought through is how the Distribution
class is supposed to know that 'fortran_extensions' is a valid option.
Perhaps I'll continue to punt on checking options for validity, although
it is nice to catch typos!  Also, in the current model you'd have to
subclass the 'Build' class (which implements -- surprise! -- the 'build'
command) so that it calls build_py, build_ext, and build_fortran.
Perhaps there should be a mechanism to adjust the "wrapper" commands
(currently 'build' and 'install') so they can call more than just the
commands hard-coded into them.

        Greg
-- 
Greg Ward - software developer                    gward@cnri.reston.va.us
Corporation for National Research Initiatives    
1895 Preston White Drive                      voice: +1-703-620-8990 x287
Reston, Virginia, USA  20191-5434               fax: +1-703-620-0913