[Distutils] Compiling / Installing extensions
Sat, 5 Feb 2000 09:20:26 +0000
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 firstname.lastname@example.org 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.
>My preferred solution is to put platform-dependent code into
>build_ext.py, as you can see in the current kludge for handling .def
>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...
>Distutils-SIG maillist - Distutils-SIG@python.org