>>>>> "NS" == Neil Schemenauer <nas@arctrix.com> writes: >> When I was working the nested scopes, building was tedious at >> times because a change to funcobject.h meant that, e.g., >> newmodule.c needed to be recompiled. The Makefiles didn't >> capture that information, so I had been adding it to the >> individual Makefiles, e.g. >> >> newmodule.o: newmodule.c ../Include/funcobject.h >> >> (I think this worked.) NS> Hmm, I don't think so. Which makefile did you add this to? Just to clarify: I added this line to the old Makefile before you checked the new one in. NS> Hmm, I don't think so. Which makefile did you add this to? Are NS> you using the new makefile? The Makefile.pre.in file contains a NS> line like: NS> $(LIBRARY_OBJS) $(MAINOBJ): $(PYTHON_HEADERS) NS> but newmodule.o not in LIBRARY_OBJS. By default its not NS> compiled by make but with distutils. If you add newmodule to NS> Setup then a line like: NS> Modules/newmodule.o: $(PYTHON_HEADERS) NS> would do the trick. I think I will add a line like: NS> $(MODOBJS): $(PYTHON_HEADERS) NS> to fix the problem. NS> I could easily restore the mkdep target but my feeling right now NS> that explicitly including the header dependencies is better. NS> What do you think? Isn't it overkill to have every .o file depend on all the .h files? If I change cobject.h, there are very few .o files that depend on this change. I suppose, however, it's not worth the effort to get it right at a finer granularity, e.g. that the only files that depend on cobject.h are cobject, cStringIO, unicodedata, _cursesmodule, object, and unicodeobject. Jeremy
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