[Distutils] More (Windows) comments on distutils-0.1.2

Robin Becker robin@jessikat.demon.co.uk
Tue, 18 Jan 2000 00:08:37 +0000


In article <20000117153950.C9793@cnri.reston.va.us>, Greg Ward
<gward@cnri.reston.va.us> writes
>On 13 January 2000, Thomas Heller said:
>> 1. Python extensions for Windows MUST be linked with
>> the /MD switch to use the multithreaded runtime
>> library. Optimizations are also enabled by the following
>> line:
>> 
>> > class MSVCCompiler (CCompiler) :
>> >     def __init__ (self,
>> >         [...]
>> >         self.compile_options = [ '/nologo', '/Ox', '/MD', '/GD' ]
>
>I haven't seen any disagreement with this, so I'll take your word for
>it.  I'd feel more comfortable if another Python/Windows extension
>developer would speak up and say, "Yep, that's the Right Thing to do".
>(Mark?  Guido?)

/GD is for a DLL specific optimisation 

>
>So what are the flags here?  I assume /Ox is for optimization; you said
>/MD selects the multithreaded RT library.  What is /GD for?
>
>
>> 2. In build_ext.py I find the following code:
>> 
>[...code to deal with .def files elided...]
>
>> Doesn't this belong into msvccompiler.py?
>
>If anywhere at all.  I really, really dislike this whole .def file
>thing, and I don't like them cluttering up the build options dictionary
>or the build_ext command class.  But I don't know how else to do it,
>because I know about as much about Python on Windows as I do about
>skateboarding on Pluto.
>
>> We do not need any stinkin' DEF-files, if we use the link options
>> /EXPORT and /BASE. The following code builds the required arguments:
>
>Hallelujah!  I've been waiting for someone to say this.  Ever since I
>found out what .def files are, I've been wondering why the heck they are
>needed. 

.def files are for exporting things which aren't declared exported in
the code. They're not needed if you use the MSVC specific declarators.

>
>> >        if def_file is not None:
>> >            extra_args.append ('/DEF:' + def_file)
>> >        else:
>> >            # if no def file is found, export the init<name> function
>> >            # and calculate a random base address
>> >            extra_args.append ('/EXPORT:init' + extension_name)
>> >            import whrandom
>> >            base = whrandom.randint (0x1000, 0x8000) * 0x10000
>> >            extra_args.append ('/BASE:0x%x' % base)
>
>But this looks weird: a random base address?  What the heck is going on
>here?  Again, could another Python-on-Windows expert speak up?  Nothing
>personal, Thomas, but I don't want to take the word of just one person
>on this code, and I'd like to know what the heck the random base address
>is all about.
>

Please don't bother to use random addresses. If you're lucky your build
may make a very small difference. Ideally under windows all the dlls
needed for a given application should have non intersecting default
address ranges. See the file PC/dll_base.txt in the source distribution.
However, this is only a minor optimisation and it seems that Guido has
abandoned it in favour of simplicity. In a distribution where all the
dlls are fixed it might be worth rebasing all of the dlls. The random
hack may work, but is not guaranteed to avoid base clashes.

>Thanks for the code -- now let's hear from some other voices as to
>whether this is the Right Thing to add to Distutils to compile
>extensions with MSVC.  Anyone?
>
>        Greg

-- 
Robin Becker