RE: Shorter and less error-prone rule for automatic prerequisite generation in the GNU Make manual

[Martin Dorey]

>> If an update to new source code, that would compile just fine in a clean 
>> checkout, breaks the incremental build, the build system is errornuous.

> I would like to agree with you, but this constraint is, in general,
> incompatible with incremental building

That's a entertainingly provocative claim.  I'm not convinced that it's been 
demonstrated and, further, I don't believe it to be true.  Where we parted 
company was here:

>>> Speaking of the subtleties of dependency tracking: do an update in
>>> your version control system, watch some header go away - and all files
>>> that used to reference it drop those references.  Your .d files claim
>>> a bunch of stuff depends on this missing file; but you have no rule to
>>> regenerate it.

You don't need to regenerate it.  In a make-using system that I maintain, but 
am not allowed to share with you (which was why I bit my tongue earlier - not 
very public-spirited of me), there's a .DEFAULT rule, which essentially does:

echo Pretending to have generated $@ 1>&2

Now, lying to the computer, like I am there, often doesn't end well.  Having a 
default target that claims to be able to build anything, if that's what I had, 
would cause pain when debugging the makefiles.  There may be other aspects of 
the system I'm using, which I haven't shared and perhaps am not even aware of, 
which are saving me from falling into trouble due to these caveats.  However, 
in my experience and opinion, these issues are not as serious as losing 
incremental building.

-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Edward Welbourne
Sent: Thursday, April 29, 2010 08:00
To: Robert Jørgensgaard Engdahl
Cc: address@hidden
Subject: Re: Shorter and less error-prone rule for automatic prerequisite 
generation in the GNU Make manual

> If an update to new source code, that would compile just fine in a clean 
> checkout, breaks the incremental build, the build system is errornuous.

I would like to agree with you, but this constraint is, in general,
incompatible with incremental building, which is too good a benefit to
throw away.

> Anything that seeks to fix such bugs by user intervention is not a real
> solution. At least that is my opinion. I just don't know how that could be
> solved nicely in Make.

Quite.  In the mean time, we get as close to this ideal as possible
and we have clean-rules to purge selective chunks of what incremental
building normally caches for us, to deal with the messy cases.

If people *routinely need* to use any clean rule in the course of
their normal work-flows, I consider the build system inadequate: but
I'll still include clean rules for use when the exceptional situations
do come up (and as an aid to debugging).

        Eddy.


_______________________________________________
Bug-make mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/bug-make