Bug#309596: tetex-base: FTBFS in experimental: Endless loop.

[Florent Rougon <f.rougon@free.fr>]

Hilmar Preusse <hille42@web.de> wrote:

> Sure. Here we go.

Thanks.

As you can see, when the second debug snippet is written, Make has
already taken the wrong decision of rebuilding debian/rules (the fact
that the snippet is printed means that Make is running the commands to
update debian/rules):

2005-05-19 15:32:53.370000000 +0200 debian/COPYRIGHT.scripts
2005-05-19 15:37:24.000000000 +0200 debian/common.functions
2005-05-19 15:32:53.400000000 +0200 debian/common.variables
2005-05-19 15:41:43.750000000 +0200 debian/rules
2005-05-19 15:41:29.700000000 +0200 debian/rules.in
2005-05-19 15:32:53.840000000 +0200 debian/variables

debian/rules is newer than all its prerequesites, yet Make wants to
rebuild it. With the next loops, things only get worse as the
prerequesites for debian/rules aren't updated anymore, but debian/rules
gets newer after every loop.

The reason for debian/rules being updated each time is, I think, due to
the commonstuff_update prerequesite in the rule:

  % :: %.in commonstuff_update $(eperl_sourcefiles)

since $(eperl_sourcefiles) is a subset of the files listed in the debug
snippets.

commonstuff_update is a phony target (it is not the name of a file to
update). If I remove it from this rule, debian/rules is updated only
once (not twice anymore), which is exactly what I expect. Also, the GNU
Make manual says about phony targets:

    A phony target should not be a prerequisite of a real target file;
  if it is, its commands are run every time `make' goes to update that
  file. As long as a phony target is never a prerequisite of a real
  target, the phony target commands will be executed only when the phony
  target is a specified goal (*note Arguments to Specify the Goals:
  Goals.).

(goals are the targets specified on the command line, such as "clean"
when running "debian/rules clean", or the first target if none is
specified)

So, the Make manual discourages the use of a phony target in this place.
Maybe this can explain the weird behaviour.

Could you try to remove "commonstuff_update" from the double-colon rule
and tell us if it loops again (and if so, attach the log file with the
debug snippets)? Normally, removing it from rules.in only should be
sufficient since after the first update, debian/rules will have the
double-colon rule without "commonstuff_update".

If this solves the problem, I'll post a patch where commonstuff_update
is implemented with a "define" or an external shell script, and called
in the command sequence for the "clean" target (since Frank made clean
depend on commonstuff_update) and maybe also in that of the double-colon
rule.

Regards,

-- 
Florent