Kurt Roeckx <[EMAIL PROTECTED]> wrote:
> Note that I'm doing this on a 2.6 kernel, which has sub-second
> timestamps on files, which might be why you're not seeing it.
Good to know (I'm working with a 2.4 kernel). Now, I have a possible
explanation:
Suppose we start debian/rules with the rules file in 3.0-3.
10 Make sees this rule:
% :: %.in $(eperl_sourcefiles)
eperl -P -o $@ $<
The rule applies to the Makefile being executed (debian/rules),
therefore Make will see if it needs to be updated. In the
$(eperl_sourcefiles) prerequesite, it sees the two .PHONY
prerequesites, *automatically* runs the corresponding targets because
they are .PHONY (this is a hypothesis I am making to explain the
whole thing), and then, only then, checks whether debian/rules is
older than any of the prerequesite files, in particular
debian/common.variables and debian/common.functions that have just
been updated by the .PHONY target.
On your system, this is always the case because of the subsecond
timestamps. Therefore, debian/rules is regenerated and make reruns
itself with the new one. GOTO 10. :-)
On my and Frank's systems, the loop quickly breaks because it is easy to
do the following in less than 1 second:
- Make regenerates debian/rules
- Make reruns itself with the new rules file
- Make runs the .PHONY targets and updates common.variables and
common.functions
Now, Make checks the time stamps of the new debian/rules and the
newer-but-still-generated-in-the-same-second common.variables and
common.functions, sees that they are all equal and concludes that rules
doesn't need to be regenerated. Thus, the build can start normally.
> The patch seems to work, and it seems to have build fine now.
Good, thanks.
--
Florent
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
