On donderdag, augustus 8, 2002, at 07:16 , Martin v. Löwis wrote:
Guido van Rossum <guido@python.org> writes:
Let me turn this around. What advantage do you see to linking it statically?
The trigger was that it would have simplified the build for me: When converting VC++6 projects to VC.NET, VC.NET forgets to convert the /export: linker options, which means that you had to add them all manually. Mark has fixed this problem differently, by removing the need for /export:.
Integrating _sre (and _socket, select, winreg, mmap, perhaps others) into python.dll still simplifies the build process: you don't have to right-click that many subprojects to build them.
In addition, it should decrease startup time: Python won't need to locate that many files anymore.
It also decreases the total size of the binary distribution slightly.
Note that I went exactly the other way for MacPython over the last year. It used to be so that all "common" modules were included in PythonCore.slb, and I used separate project build files only for Mac-only modules and one or two special cases (Tk, expat). I bit the bullet half a year ago and made PythonCore.slb lean and mean, but still used my own private project build file generator for all extension projects. I bit the bullet again (actually, I bit one of the two remaining half-bullets, I've kept the Mac-specific modules as they are) last month, and MacPython now uses the main setup.py for a large collection of the cross-platform extension modules. This turned out to be only one or two evenings of work. This has immediately resulted in a decrease in my workload: whereas previously whenever someone decided to add the kaboozle module I had to add project files for this, etc etc etc, all that is now often taken care of by distutils and setup.py. -- - Jack Jansen <Jack.Jansen@oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -