[Python-Dev] Makefile changes

Jeremy Hylton jeremy@alum.mit.edu
Fri, 26 Jan 2001 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