Re: rebuilding of makefiles vs. headers

[Stepan Kasal]

Hello Dan,

On Fri, Jun 03, 2005 at 03:15:50PM -0400, Dan Manthey wrote:
> One of the last steps that ./config.status does when making config.h is to
> check whether the newly generated file differs from that being replaced,
> and if it does not, the old one is not overwritten.  This is done to
> reduce unnessary rebuilding of source dependented on config.h.  This I
> understand.
> 
> But the similar check for non-modification of generated makefiles is
> commented out in status.m4.  Why is this?  There's a crypic "This would
> break Makefile dependencies." in the comment, but I don't understand how.
> Could someone enlighten me?

Not only generated makefiles; this hold for generated files in general.
The makefile has a rule which says how to refresh those files; roughly:

Makefile: Makefile.in ./config.status
        ./config.status Makefile
foo: foo.in1 foo.in2 ./config.status
        ./config.status foo

If config.status wouldn't touch the output file, the rule would be
triggered each time make is invoked.  That would slow down things.

config.h is worth a special treatment, as lot of files depend on it.
But Automake has a lot of work with this, see an Automake-generated
Makefile in a directory with a config.h.  There cannot be the dependency
        config.h: config.h.in
Instead, there is a rule for stamp-h1,...

Please also note that the code in status.m4 for CONFIG_FILES code
contains a hook which is used by Automake to create the stamp-h1 file.
Without this the makefile would ignore the config.h created by
configure and would call config.status to re-create it.

As I said, this is still worth it for config.h.  But you don't want
to repeat this for other generated files.

A final remark:  autoheader doesn't update config.h.in if it doesn't
change.  But the Automake-generated rule does "touch config.h.in".
(The other possibility would be to use a stamp file---but that would
be too complicated.)
So Automake effectively cancels this feature of autoheader.
You might ask why autoheader has this feature; well perhaps someone,
in a distant galaxy, might be using it...  It's not worth any effort.
(You can occassionally see a spare run of autoheader if you ran
autoheader manually before make.)

Hope this explains it,
        Stepan