[Python-Dev] _sre as part of python.dll
Guido van Rossum
Thu, 08 Aug 2002 13:26:23 -0400
> > 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.
I never have to do that; the dependencies in the project file make
sure that the extensions are all built when you build the 'python'
> 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.
Maybe _sre is used by most apps (though I doubt even that). But
_socket, select, winreg, mmap and the others are definitely not. On
Unix, all extensions are built as shared libraries, except the ones
that are needed by setup.py to be able to build extensions; it looks
like only posix, errno, _sre and symtable are built statically.
I'd say that making more extensions static on Windows would increase
start time of modules that don't use those extensions.
I'm -0 on doing this for _sre (I think it's a YAGNI); I'm -1 on doing
this for other extensions.
--Guido van Rossum (home page: http://www.python.org/~guido/)