rebuilding of makefiles vs. headers

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

rebuilding of makefiles vs. headers

Dan Manthey
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?

-Dan




_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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


_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf
Loading...