Larry Hastings wrote: > First and foremost: turning off Py_USING_UNICODE *breaks the build* > on Windows.
Probably nobody does that nowadays. My own feeling (but I don't have numbers for backing it up) is that the biggest size in the .DLL is represented by things like the CJK codecs (which are about 800k). I don't think you're gaining that much by trying to remove unicode support at all, especially since (as you noticed) it's going to be maintenance headhache. > Second of all, the dumb-as-a-bag-of-rocks Windows linker (at least > the one used by VC++ under MSVS .Net 2003) *links in unused static > symbols*. If I want to excise the code for a module, it is not > sufficient to comment-out the relevant _inittab line in config.c. > Nor does it help if I comment out the "extern" prototype for the > init function. As far as I can tell, the only way to *really* get > rid of a module, including all its static functions and static data, > is to actually *remove all the code* (with comments, or #if, or > whatnot). What a nosebleed, huh? This is off-topic here, but MSVC linker *can* strip unused symbols, of course. Look into /OPT:NOREF. > So in order to build my *really* minimal python24.dll, I have to hack > up the source something fierce. It would be pleasant if the Python > source code provided an easy facility for turning off modules at > compile-time. I would be happy to propose something / write a PEP > / submit patches to do such a thing, if there is a chance that such > a thing could make it into the official Python source. However, I > realize that this has terribly limited appeal; that, and the fact > that Python releases are infrequent, makes me think it's not a > terrible hardship if I had to re-hack up each new Python release > by hand. You're not the only one complaining about the size of Python .DLL: also people developing self-contained programs with tools like PyInstaller or py2exe (that is, programs which are supposed to run without Python installed) are affected by the lack of a clear policy. I myself complained before, especially after Python 2.4 got those ginormous CJK codecs within its standard DLL, you can look for the thread in Google. The bottom line of that discussion was: - The policy about what must be linked within python .dll and what must be kept outside should be proposed as a PEP, and it should provide guidelines to be applied also for future modules. - There will be some opposition to the obvious policy of "keeping the bare minimum inside the DLL" because of inefficiencies in the Python build system. Specifically, I was told that maintaining modules outside the DLL instead of inside the DLL is more burdesome for some reason (which I have not investigated), but surely, with a good build system, switching either configuration setting should be the matter of changing a single word in a single place, with no code changes required. Personally, I could find some time to write up a PEP, but surely not to pick up a lengthy discussion nor to improve the build system myself. Hence, I mostly decided to give up for now and stick with recompiling Python myself. The policy I'd propose is that the DLL should contain the minimum set of modules needed to run the following Python program: ------------------- print "hello world" ------------------- There's probably some specific exception I'm not aware of, but you get the big picture. -- Giovanni Bajo -- http://mail.python.org/mailman/listinfo/python-list