Re: Mutilated stdlib.h

[Ralf Wildenhues]

* Bruno Haible wrote on Sat, Apr 02, 2011 at 02:00:56AM CEST:
> > The autotools go to a lot of
> > trouble to make it possible to rerun make and rebuild the 
> > infrastructure without resorting to the big hammer of make *clean.
> > This is very useful.  So gnulib breaks that now?
> 
> It's not gnulib that breaks it.

Well, without gnulib you would hardly ever have to do it, with many
projects.  I have GCC build trees tracked across several months.

> It's that it's unreliable. The autotools
> don't cope automatically with .m4 files that have been renamed,

That is simply not true with Automake 1.11 any more.

> m4 macros that have been renamed,

Can you show an example for this?

> conditional use of AC_CONFIG_LINKS when the condition has changed,

I agree that this is currently a problem.  However, removing all links
manually is a very cheap operation, also, because re-instating them by
'make' later usually won't cause a rebuild flood as the time stamps of
the linked-to file count, which are still old.  IOW, this is easily
worked around.

> source .h files that have been renamed or removed,

I would like to see evidence for this as well.

> and so on. Such situations are quite rare when someone works in an isolated
> project, but become not so rare when people use gnulib.

Please, we should strive to get such issues working when possible.
It is just not scalable to do a distclean in large projects where
gnulib is but one (or a few) small islands but the world takes
forever to build.  Scalability is very important if gnulib is to
be picked up more in such settings.

For example, I sumbitted a (still pending) patch to Autoconf a
couple of weeks ago to get 'make' to still work in the presence
of a new AC_CONFIG_SUBDIRS entry.

> Since blindly rerunning "make" is unreliable, I find that people should
> know that "make distclean; ./configure; make" is more reliable, since that
> will save them time.

FWIW, I fully understand your strategy in recommending this to users.
I would probably do the same in your position, if only to save myself
the hassle of remote-debugging a tricky and hard-to-reproduce condition.
But from a developer POV, I consider it unacceptable that the build
system will out of principle not allow me to do incremental rebuilds.

At the very least, it ought to be possible to determine at gnulib-tool
run time whether continuing with a rebuild is feasible or not; so that
in the majority of cases a full bootstrap won't be needed.

Thanks,
Ralf