[Python-Dev] Makefile changes
Jeremy Hylton
jeremy@alum.mit.edu
2001年1月26日 12:58:24 -0500 (EST)
>>>>> "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