[Distutils] Compiling / Installing extensions

[Thomas Heller]

> > 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.
> 
Only one change neccessary, in sysconfig.py line 150:
    g['SO'] = '.dll'
make this:
    g['SO'] = '.pyd'

> > 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.
> 
The current msvccompiler.py I sent to you
adds the /INCREMENTAL:No flag to the linker,
which will suppress the .ilk file (used for incremental linking).

The generation of .exp and .lib files cannot be suppressed
by command line flags.

If you want to use msvccompiler.py in a way you described above,
we cannot simply delete the .exp and .lib files because they
may be needed for dependent modules to be build.
Wouldn't it be better to change install_ext to only copy the expected
files?

> > 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
If we start to compile debug version, we will have to struggle
with the .pdb file, the 'program database' containing debugging
information.
What do other windows developers think? Should we link with /pdb:None,
which will write the debugging info into the executable? Or should we
live with the .pdb file in the same directory as the .pyd?

Thomas