distutils for scientific stuff, was RE: [Numpy-discussion] RPMs out of date, have problems

[Paul F. Dubois]

About doing different things in distutils for different platforms, that
is easy. It is a Python script so you can set things depending on
sys.platform.
E.g. from Numerical,

# You might need to add a case here for your system
if sys.platform == 'win32':
    mathlibs = []
    define_macros = []
    undef_macros = ['HAVE_INVERSE_HYPERBOLIC']
elif sys.platform == 'beos5':
    mathlibs = []

Later the setup call uses these variables in its argument list.

Adding Fortran support is quite a bit more difficult because the whole
idea of distutils is to piggy-back off the Python configure, which
doesn't configure Fortran compiler options or paths. I don't think
distutils ought to try, really. You just compile the Fortran into a
library and then use that in your setup.py. 

I think a possible way out is scons, but that is just a preliminary
impression. It bears a strong resemblance to the system I was working on
in 1998 and abandoned when I changed jobs.

My theory was that the build should be rule-based, with finer and finer
rules for special cases or platforms. The highest priority rule that
governs a particular file, wins.

E.g., 
Rule 1: To compile a .c file, do cc -O ...
Rule 2: To compile foo.c, do cc -O3 ...
Rule 3: To compile foo.c on platform win32, do cc -O1 ...
Rule 4: compile bar.c but only on platform win32

There was more to it, because one of the tricky points is that nowadays
files produce multiple outputs per execution and may need to be
processed in more than one way. 

Note that if you add a new .c file or a new platform, you're covered
unless it needs special treatment.

Anyway, this is actually not a design area the numerical community ought
to try to get into; there are people who have spent a lot of time on
this already. Given that sentence, I can't explain why I was doing it,
other than that I hate make so badly I was driven to it. The project was
called MMD: Make Must Die.