[Distutils] Compiling / Installing extensions

[Greg Ward]

On 04 February 2000, Thomas Heller said:
> It seems, with Robins latest patch compiling extensions
> under windows goes smoothly.

Great!  I got a bit lost in the flurry of patches-to-patches, so could
one of you mail me either a definitive patch or a replacement version of
msvccompiler.py with the "let's go find the compiler" code included?
(Send it to gward@python.net so I'll get it at home.)

> 1. Usually extensions are named xxx.pyd, not xxx.dll
> Should this be changed?

Definitely -- the "foo.pyd wraps foo.dll" argument is compelling.  FWIW,
msvccompiler.py is *not* the place to fix this.  The CCompiler classes
are meant to apply to more than just compiling Python extensions, but
rather to know "everything" about compiling and linking C on a given
platform/compiler.  Unfortunately, the rest of the Distutils tries
really hard to be platform-neutral, which means this kind of stuff --
which is specific to building Python extensions on a given platform --
falls between the cracks.

My preferred solution is to put platform-dependent code into
build_ext.py, as you can see in the current kludge for handling .def
files.

That reminds me, I've been convinced on several occasions that .def
files are not necessary (since Python extensions really only need to
export one symbol, 'init_foo()' or whatever it is, which can easily be
specified on the compiler command-line).  I'd love to see that
MSVC-specific kludge stripped out of build_ext.py, but I think this
requires some other changes:

  * notion of "list of symbols to export" when building a shared
    object or library (in CCompiler and all subclasses -- it would
    just be ignored in UnixCCompiler)
  * build_ext passes ['init_%s' % extension_name] for that
  * MSVCCompiler generates the appropriate command-line options for
    cl.exe to export the listed symbols

If any of you intrepid Windows hackers would like to tackle this, be my
guest!  And feel free to do whatever cleanup you like in
msvccompiler.py; there is definitely some cruft in there.

> 2. install copies all files built: not only the dll but also
> .exp, .lib, everthing which is output by the linker.
> Is this also the case on unix?
> Or is my setup.py wrong?

Wow, I had no idea this was happening.  That should be the job of
MSVCCompiler to clean up, since it "knows everything" about the compiler
and platform, eg. what crufty turds it drops behind after compiling or
linking something.  Silly me, I blithely assumed that no compiler would
be so stupid as to leave unnecessary temporary files around after a
build.  I should never have underestimated Microsoft's capacity for
mind-numbingly stupid code.

> 3. It would really be nice if there were a possibility to
> compile debug versions.

Shouldn't be too hard; just need to add:

  * debug flag to CCompiler instances
  * debug flag to CCompiler methods (the usual "method param overrides
    instance attribute" paradigm I've used everywhere in those classes)
  * UnixCCompiler sticks "-g" into the command line if debug is true
  * MSVCCompiler sticks "**something**" into the command line if debug
    is true
  * build_ext and build_lib should take 'debug' options, which can
    be set on the command line

I think if all this is done, then

  setup.py build_ext --debug

will do what you want on either Unix or Windows.  If I don't get a patch
for it this weekend, I'll do it myself...

        Greg