[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 17:51:44 -0500
On Wed, Aug 4, 2010 at 5:32 PM, Philip Guenther <address@hidden> wrote:
> 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.
My main point is that recursive make may not always be harmful. You
point is that recursive make is harmful. I have given your the case
why I think that it is not harmful.
The only minor drawback of my way of recursive make is that make has
to go in some directory to check even if it doesn't have to do so. But
this recursive make doesn't make any dependency error, which is
different from what claimed in the "recursive make considered harmful"
In a customizable build system such Scons, I believe that
not-to-trace-to-the-root is possible to be implemented. I don't think
that the fact that GNU make can not do so justify recursive make is
> 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
> $ make
> echo b.txt
> echo all
> 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
> for c.txt.
In a usually build system, people should only use make to modify the
files. Therefore, your example is really not applicable.