In article <20000204230137.B22123@cnri.reston.va.us>, 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.)
Thomas has the latest working version
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. ....
agreed
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
This is certainly doable. The compile.py from used to do that.
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
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://www.python.org/mailman/listinfo/distutils-sig
-- Robin Becker