>> 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: bug-make-bounces+mdorey=bluearc....@gnu.org [mailto:bug-make-bounces+mdorey=bluearc....@gnu.org] On Behalf Of Edward Welbourne Sent: Thursday, April 29, 2010 08:00 To: Robert Jørgensgaard Engdahl Cc: bug-make@gnu.org 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 Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make _______________________________________________ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
