[Python-Dev] _sre as part of python.dll
Guido van Rossum
Thu, 08 Aug 2002 13:49:55 -0400
> > 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.
> Are you sure? If the python target is up-to-date (i.e. nothing has to
> be done for python_d.exe), and I delete all generated _sre files
> (i.e. sre_d.pyd, and the object files), and then ask VC++ 6 to build
> the python target, nothing is done.
> Indeed, I cannot find any place where it says that the python target
> is related to _sre. I can only see dependencies with pythoncore.
> Can you (or any other regular pcbuild.dsp user) please guess what I'm
> doing wrong?
I have no idea. It's all magic for me. But I never delete targets
> > 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 do believe that is a mistake, as it will increase startup time of
> applications that need them; applications that don't need them would
> not be hurt if they were in the python binary.
But is the startup time of apps that use a lot of stuff the most
important thing? I'd say that the startup time of apps that *don't*
use a lot of stuff is more important. I'm not sure that making the
binary bigger doesn't slow it down.
> > I'd say that making more extensions static on Windows would increase
> > start time of modules that don't use those extensions.
> I guess I have to measure these things.
Yes, please. We switched to building almost all extensions as shared
libs when we switched away from Modules/Setup to setup.py.
--Guido van Rossum (home page: http://www.python.org/~guido/)