Re: [CRAZY PROPOSAL] Automake should support only GNU make

[Paul Smith]

On Thu, 2011-01-13 at 20:38 +0100, Ralf Wildenhues wrote:
> * Bob Friesenhahn wrote on Thu, Jan 13, 2011 at 08:32:01PM CET:
> > On Thu, 13 Jan 2011, Ralf Wildenhues wrote:
> > >You can implement hash-based dependencies inside GNU make if you like.
> > >Or another make.  Maybe someone has even done so already.  It has little
> > >to do with Automake.
> > 
> > I have never heard of such a thing implemented in make.  It would
> > surely bloat the makefile by more megabytes or be excruciatingly
> > slow.
> 
> That's not what I meant.  You can hack the source code of GNU make
> with the goal to (optionally) replace timestamp-based dependencies
> with file-hash-based depdendencies.  No changes at all in any user
> makefiles.  It's not a large change even.  IIRC somebody has done
> this already, it just hasn't been merged upstream.

It's not QUITE so simple.  The advantage to using timestamp-based
dependencies is that the filesystem is your database of
"out-of-dateness", and the kernel ensures that the behavior of that
database is well-defined.

If you want to use anything more sophisticated to determine
"out-of-dateness", then make has to keep its own database to remember
the previous state, so it can be compared.  Granted this is not rocket
science but there are some tricky bits to it: it needs to be pretty
portable to the various architectures make supports; it needs to be
well-behaved in the case of a missing database, and in the case of
multiple instances of make running in the same directory at the same
time; what happens if the database is corrupted or somehow contains the
wrong information; etc.

Making this robust enough to trust it with your builds requires some
thought and care.

> BTW, Nathanael's propositions in this thread go in the same direction:
> http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01504.html

There was a set of work done to introduce "user-defined out-of-date
functions" into GNU make, a few years ago.  That didn't end up getting
merged because it seemed too complex to me, both from a make developer
and make user standpoint.

I agree with Nathanael, although I take serious issue with his statement
"the GNU make people were completely uninterested, since they didn't get
why it was a good idea"--that is simply not true.

What is true is that Nathanael posted a 10,000ft-level description of
what he wanted, not completely thought-out, and when I replied to his
message with some discussion of the idea and potential problems with it,
he never followed up.