bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU make suggestion: did the dependency really change?


From: Paul D. Smith
Subject: Re: GNU make suggestion: did the dependency really change?
Date: Fri, 2 Nov 2001 15:11:09 -0500

%% Henning Makholm <address@hidden> writes:

  >> %.ui : %.sig
  >>    @[ -f $@ ] && mv $@ address@hidden
  >>    mosmlc -c $<
  >>    @cmp -s $@ address@hidden && mv address@hidden $@

  hm> Hm (checks it..) it works. Amazing. Where should I have looked for
  hm> that behavior in the documentation?

I don't think it's explicitly documented in the GNU make manual.
However, (a) every make has always behaved this way, so it's probably
documented in other make manuals, and (b) it's inferable from other
descriptions: the manual says that the target is built based on
comparing it to the mod time of each of its prerequisites, so if the
prerequisite's mod time doesn't change (as above where we "unchange" it
if the file hasn't changed) then the target won't be rebuilt.

  hm> (at least sufficient enough to keep me from hacking around in the
  hm> source for make).

:)

  >> Instead, the fundamental problem should be addressed: the problem
  >> I'm thinking of is the stateless nature of make.  Make needs the
  >> ability to remember state from previous builds

  hm> This would be a really good idea - it would probably solve some of
  hm> my other little itches too - but is not something I can spare the
  hm> time to attack.

The theory here is not difficult, but the implementation details get
gross, when you consider recursive invocations of make, possibly in the
same directory, the different platforms make supports, etc.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://www.paulandlesley.org/gmake/
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist



reply via email to

[Prev in Thread] Current Thread [Next in Thread]