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.
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
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? live with the .pdb file in the same directory as the .pyd? Thomas