[Top][All Lists]

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

Re: Dependencies of dependencies across make implementations.

From: Paul Smith
Subject: Re: Dependencies of dependencies across make implementations.
Date: Sat, 23 May 2009 19:37:25 -0400

On Sat, 2009-05-23 at 20:49 +0100, sarah fox wrote:
> $ cat Makefile
> all: file
> file.c: file.h
>       @:

> The theory is that editing file.h will cause file.c to be recompiled due to 
> the
> dependency chain file.o -> file.c -> file.h.
> BSD make appears to get this right:
> As does Solaris, HPUX and IRIX make.
> GNU make does not:
> $ make
> cc -o file.o -c file.c
> cc -o file file.o
> $ touch file.h
> $ make
> $
> Is there a method to make GNU make behave "correctly" without
> introducing GNU make specific syntax?

I'm surprised that these versions of make behave this way.  Although not
stated explicitly, the POSIX standard for make seems pretty clear (to
me) that GNU make's behavior is the correct one in this situation.  It

> The make utility attempts to perform the actions required to ensure
> that the specified targets are up-to-date. A target is considered
> out-of-date if it is older than any of its prerequisites or if it does
> not exist. The make utility shall treat all prerequisites as targets
> themselves and recursively ensure that they are up-to-date, processing
> them in the order in which they appear in the rule. The make utility
> shall use the modification times of files to determine whether the
> corresponding targets are out-of-date.
> After make has ensured that all of the prerequisites of a target are
> up-to-date and if the target is out-of-date, the commands associated
> with the target entry shall be executed. If there are no commands
> listed for the target, the target shall be treated as up-to-date.

Because your rule for file.c: file.h does not actually change the
modification time of file.c, any rule that depends on file.c cannot
consider it out of date solely because file.h is newer.  This is the
behavior GNU make provides.

In fact, this behavior is quite commonly relied on to provide for
situations where a target can be determined to not need to be updated,
even though its prerequisites were modified (a kind of "rebuild only if
changed" rule).  There is no way GNU make's behavior can be modified to
match the description you give above, without breaking thousands of

Also, there is no option you can provide to GNU make that will change it
to work this way.

You could, of course, change your makefile to make what you want
explicit, such as:

        file.c: file.h
                @touch $@

but I'm not sure that this is acceptable; changing the modification time
on files like this has other consequences, since editors etc. use that
metadata as well.  Philip's suggestion of choosing an alternate method
for tracking prerequisites is, I think, the better idea.

 Paul D. Smith <address@hidden>          Find some GNU make tips at:            
 "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]