unexplained behavior in autoconf-style stamp-h/config.h rule

[Peter Eisentraut]

Attached is a minimal test case related to an Autoconf-style build
system.  The Autoconf manual recommends in section "Automatic Remaking":

    You can put rules like the following in the top-level
    `Makefile.in' for a package to automatically update the
    configuration information when you change the configuration
    files. [...]

     config.h: stamp-h
     stamp-h: config.h.in config.status
             ./config.status

Now add to that some file to compile, e.g.,

    all: test.o

    test.o: test.c config.h

If the tree is fully built and config.h.in is updated (touch
config.h.in), then it takes *two* invocations of make to get everything
built:

$ touch config.h.in
$ make
./config.status
$ make
cc    -c -o test.o test.c
$ make
make: Nothing to be done for `all'.

This is obviously broken.

A working fix appears to be to use

    config.h: stamp-h ;

instead.  Indeed, the rules generated by Automake effectively do this
(with some additional decoration), so this seems to be a recognized
problem.

But I'd like to understand why this happens.  The only vague theory I
have is that make thinks, since there are no commands attached to
config.h, it cannot possibly be updated, so don't bother checking
anything that has it as a prerequisite.  But neither the GNU make manual
nor make --debug really explain this.

Any ideas?

Also, is the Autoconf manual definitely wrong, and should it be fixed?

make-testcase.tar.gz
Description: application/compressed-tar