[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Recursive make may not always be harmful? (was Re: Hierarchical make
Re: Recursive make may not always be harmful? (was Re: Hierarchical make: How to avoid unnecessarily going into certain directories?)
Wed, 4 Aug 2010 15:32:49 -0700
On Wed, Aug 4, 2010 at 3:12 PM, Peng Yu <address@hidden> wrote:
> My main point in the previous email is that recursive make may not
> always be harmful. With the way that I show in the following email,
> the drawback of recursive make can be eliminated.
> Could anybody comment on it and let me know in case I miss any
> scenario? Also, to make this work better, I'd like GNU make has the
> capability of not tracing all the way to the root in the dependence
> graph if nothing has been changed in the middle of the dependency
> chain. In the following example, since b.txt is not change in rule
> 'b.txt: a.txt', then there is no need to run the rule 'c.txt: b.txt'.
> Is there any special build target name in GNU make to do?
If a target is older than its dependencies, that its commands will be
run. Period. It doesn't matter if its dependencies aren't changed by
their own rebuild rules. What matter is whether it is out of date
with respect to its dependencies.
GNU make *does* do the "is this target older than its prerequisites"
test _after_ the prerequisites have been built, so when a target is
newer than all its prerequisites, if all of its prerequisites can be
updated without actually changing the files, then the target won't be
out-of-date and won't be rebuilt.
Using your example:
> .PHONY: all
> all: c.txt
> echo $@
> c.txt: b.txt
> echo $@
> b.txt: a.txt
> echo $@
$ touch b.txt ; sleep 1; touch c.txt; sleep 1; touch a.txt
b.txt is out of date with respect to a.txt, so make rebuilds it, but
it isn't actually changed, so make doesn't have to run the commands