Re: Mutilated stdlib.h

[Bruno Haible]

Ralf Wildenhues wrote:
> >   - If gnulib-tool removes the generated files stdio.h, stdlib.h, and 
> > similar,
> >     the "make" process will rebuild a majority of the .o files and all
> >     tests programs. Not much of a win, compared to running "make clean".
> 
> I agree that removing them is not a good idea.  It would be a good idea
> however if all files created at config.status run time had proper
> rebuild rules in place in the makefile.

The proposed patch from the last mail should deal with this.

Note that the gnulib .h files are created not by "./config.status" but a little
bit later, at the beginning of "make".

> Ideally, those rebuild rules 
> work lazily for headers which are included often (i.e., if the contents
> don't change, the file isn't updated).

For files that are rebuilt outside of Makefile rules, that works. For files
that are under Makefile control, this leads to situation where after a
complete "make", another "make" creates temporary files just to see that they
haven't changed. So the subsequent "make" and "make check" and "make install"
are slowed down, and "make install" does not work when run under a different
but non-root user id. All this is undesirable IMO.

> A nice and clean solution to would require a AC_CONFIG_FILES_LAZY macro
> or similar (similarly to how AC_CONFIG_HEADERS works, but it should also
> work if the second macro argument modified the output file further).

I don't think it is a good idea to move the creation of generated files
from Makefile to configure. The lesson I've learned from the AC_LIBOBJ
story is:

  !! Use configure to determine platform dependent settings, nothing more. !!
  !! Use Makefile rules to create files.                                   !!

Bruno
-- 
In memoriam Karol Wojtyla <http://en.wikipedia.org/wiki/Karol_Wojtyla>