[Distutils] Questions about distutils strategy

[Greg Ward]

On 30 November 1999, Ian Searle said:
> We are developing a cross platform debug tool for embedded systems
> that uses Python as the central foundation.  We distribute our product
> on both solaris and windows nt.  Thus, distutils looked attractive for
> building our python extensions, which are mostly C++.  This last
> weekend, I was working on an extension, and ended up punting distutils
> for two reasons:

[Please limit your messages to < 80 columns; I had to reformat it down so it
quotes nicely.]

First caveat: if building C++ extensions with Distutils actually works,
it's a happy accident.  I had nothing to do with it.  ;-)

> 1) the documentation is not adequate for a moron like me.  I needed to
> add a vendor supplied object file to the link command, and struck out
> on every attempt.  The doc gave me some clues, but was not specific
> enough to really help.  I realize that this is version 0.1.

I disagree -- the documentation isn't adequate for *anyone*, moron or
not.  You need to add an 'extra_objects' element to the dictionary that
describes how to build your extension.  Eg. if you now have:

    setup (...
           ext_modules = [('myext',
                            {'sources': ['myext.c',
                                         'support.c']
                            }
                         )]
          )

then you will need to change this to

    setup (...
           ext_modules = [('myext',
                            {'sources': ['myext.c',
                                         'support.c'],
                             'extra_objects: ['vendor.o']
                            }
                         )]
          )

In the code, see distutils.command.build_ext.BuildExt.build_extensions().
Doesn't look like extra_objects is mentioned in the USAGE file (oops).

The usual disclaimer: this has not been used in practice, just tried out
in artifical tests.  Please let me know if it works or doesn't work.

> 2) the main/compelling reason is that I have to debug the python
> extensions.  The extension implementation is normally tested, and
> debugged prior to integration into Python. But the extension layer
> often needs some debugging as we are interfacing C++ with STL
> containers to Python data types.  I can debug just fine using
> distutils on Solaris/Linux, but cannot do the same on Windows.  As far
> as I can tell, you _have_ to have a DevStudio project setup to debug
> anything under windows.  Since our product will be delivered as a
> standalone tool, including python, I do not need the distribution
> facilities of distutils, only the development. But, once I have
> developed a DevStudio project/workspace for an extension, there is
> little motivation to use distutils.

Ooh, yuck.  And here I thought that invoking the MSVC command-line
compiler directly was a feature.  David Ascher was the original
volunteer to write the MSVC interface, and his plan was (I think) to
generate a project file and then somehow invoke the build system on
that.  When Perry Stoll came along with his MSVCCompiler class, David
appeared happy to bow out... but maybe his idea needs to be
resuscitated?  Yuck.  You Windows/MSVC experts got any good ideas?

        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