[Distutils] Sample setup.py for Numeric Python

12 Sep 1999

      Hi again --

[cc'd to Paul Dubois: you said you weren't following the distutils sig
anymore, but this directly concerns NumPy and I'd like to get your
input!]

here's that sample setup.py for NumPy.  See below for discussion (and
questions!).

------------------------------------------------------------------------
#!/usr/bin/env python

# Setup script example for building the Numeric extension to Python.
# This does sucessfully compile all the .dlls. Nothing happens
# with the .py files currently.

# Move this file to the Numerical directory of the LLNL numpy
# distribution and run as:
#   python numpysetup.py --verbose build_ext
#

# created 1999/08 Perry Stoll
__rcsid__ = "$Id: numpysetup.py,v 1.1 1999/09/12 20:42:48 gward Exp $"

from distutils.core import setup

setup (name = "numerical",
       version = "0.01",
       description = "Numerical Extension to Python",
       url = "http://www.python.org/sigs/matrix-sig/",
       ext_modules = [ ( '_numpy',  { 'sources' : [ 'Src/_numpymodule.c',
                                                    'Src/arrayobject.c',
                                                    'Src/ufuncobject.c'
                                                    ],
                                      'include_dirs' : ['./Include'],
                                      'def_file' : 'Src/numpy.def' }
                         ),

                       ( 'multiarray',  {  'sources' : ['Src/multiarraymodule.c'],
                                           'include_dirs' : ['./Include'],
                                           'def_file': 'Src/multiarray.def'
                                           }
                         ),

                       ( 'umath', { 'sources': ['Src/umathmodule.c'],
                                    'include_dirs' : ['./Include'],
                                    'def_file' : 'Src/umath.def' }
                         ),

                       ( 'fftpack', { 'sources': ['Src/fftpackmodule.c', 'Src/fftpack.c'],
                                      'include_dirs' : ['./Include'],
                                      'def_file' : 'Src/fftpack.def' }

                         ),

                       ( 'lapack_lite',  { 'sources' : [ 'Src/lapack_litemodule.c',
                                                         'Src/dlapack_lite.c',
                                                         'Src/zlapack_lite.c',
                                                         'Src/blas_lite.c',
                                                         'Src/f2c_lite.c'
                                                         ],
                                           'include_dirs' : ['./Include'],
                                           'def_file' : 'Src/lapack_lite.def' } 
                         ),

                       ( 'ranlib', { 'sources': ['Src/ranlibmodule.c',
                                                 'Src/ranlib.c',
                                                 'Src/com.c',
                                                 'Src/linpack.c',
                                                 ],
                                     'include_dirs' : ['./Include'],
                                     'def_file' : 'Src/ranlib.def' } 
                         ),
                       ]
       )
------------------------------------------------------------------------

First, what d'you think?  Too clunky and verbose?  Too much information
for each extension?  I kind of think so, but I'm not sure how to reduce
it elegantly.  Right now, the internal data structures needed to compile
a module are pretty obviously exposed: is this a good thing?  Or should
there be some more compact form for setup.py that will be expanded later
into the full glory we see above?

I've already made one small step towards reducing the amount of cruft by
factoring 'include_dirs' out and supplying it directly as a parameter to
'setup()'.  (But that needs code not in the CVS archive yet, so I've
left the sample setup.py the same for now.)

The next thing I'd like to do is get that damn "def_file" out of there.
To support it in MSVCCompiler, there's already an ugly hack that
unnecessarily affects both the UnixCCompiler and CCompiler classes, and
I want to get rid of that.  (I refer to passing the 'build_info'
dictionary into the compiler classes, if you're familiar with the code
-- that dictionary is part of the Distutils extension-building system,
and should not propagate into the more general compiler classes.)

But I don't want to give these weird "def file" things standing on the
order of source files, object files, libraries, etc., because they seem
to me to be a bizarre artifact of one particular compiler, rather than
something present in a wide range of C/C++ compilers.

Based on the NumPy model, it seems like there's a not-too-kludgy way to
handle this problem.  Namely:

  if building extension "foo":
    if file "foo.def" found in same directory as "foo.c"
      add "/def:foo.def" to MSVC command line

this will of course require some platform-specific code in the build_ext 
command class, but I figured that was coming eventually, so why put it
off?  ;-)

To make this hack work with NumPy, one change would be necessary: rename
Src/numpy.def to Src/_numpy.def to match Src/_numpy.c, which implements
the _numpy module.  Would this be too much to ask of NumPy?  (Paul?)
What about other module distributions that support MSVC++ and thus ship
with "def" files?  Could they be made to accomodate this scheme?

Thanks for your feedback --

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