Re: Recursive make may not always be harmful? (was Re: Hierarchical make: How to avoid unnecessarily going into certain directories?)

[Philip Guenther]

On Wed, Aug 4, 2010 at 3:51 PM, Peng Yu <address@hidden> wrote:
> 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:
...
>>> 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.

I have not fully read your previous response about why you think
recursive make is not harmful.  I pointed you at it mainly to give you
some food for thought about what seemed (to me) to be involved in the
problem.  I may dig into your other note at some later time when I am
less distracted.


...
>> 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.

<sigh>  Usually, build systems have real rules instead of pointless
"echo $@" targets.  You supplied a makefile that you claimed
demonstrated a problem, but didn't actually describe the problem
setup.  Given the makefile that you supplied, under what circumstances
(i.e., set of files and their relative timestamps) does "make" do more
work than you think is necessary?

All I did with my combo of touch and sleep commands was try to set up
the situation that I *thought* you were describing.  If I didn't do
that accurately, well, I suggest that you clearly describe how we can
do that setup and how you think make should behave in that setup.
Lacking that, how can make be 'fixed' or a workaround developed?

To put it another way, let's say a fix for whatever problem you
believe exists was to suddenly appear; how would you write a
regression test for that change?


Philip Guenther