> > 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' project. > 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4