[Distutils] Compiling / Installing extensions

[Robin Becker]

In article <20000204230137.B22123@cnri.reston.va.us>, Greg Ward
<gward@cnri.reston.va.us> writes
>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