Hi Neil, My mail suffers delays of 12-24 hours while mail.python.org is working on some enormous backlog. So I just saw your message about a new Makefile... > Spurred on by comments made by Andrew, I spent some time last > night overhauling the Python Makefiles. I now have a toplevel > non-recursive Makefile.in that seems to work fairly well. I'm > pretty sure it still should be portable. It doesn't use includes > or any special GNU make features. It is half the size of the old > Makefiles. The build is faster and its now easier to follow if > something goes wrong. I'd like to see this! > A question: is it possible to break the Python static library up? > For example, instead of having libpython<version>.a have > Parser/parser<version>.a, Objects/objects<version>.a, etc? There > would still only be one shared library. This would speed up > incremental builds and also help Andrew with PEP 229. I'm > thinking that the Makefile do something like this: > > all: python$(EXE) > > PYLIBS= Parser/parser.a Objects/objects.a ... Modules/modules.a > > python$(EXE): $(PYLIBS) > $(LINKCC) -o python$(EXE) $(PYLIBS) ... > > Modules/modules.a: minpython$(EXE) > ./minpython$(EXE) setup.py Sounds cool to me. (Where's the patch for a shared libpython???) > AFACT, the only thing affected by splitting up the static library > is Misc/Makefile.pre.in. Is this correct? Yeah, and that should be phased out in favor of distutils anyway. Now would be a great time! --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