Philip Guenther <address@hidden> wrote on
29-04-2010 19:26:40:
> On Thu, Apr 29, 2010 at 3:59 AM, Edward Welbourne <address@hidden>
wrote:
> >> Delete a "clean-depend" rule on sight,
> >
> > I cannot agree.
> > If I write a rule to make something, I also write a rule to get
rid of
> > it. It's just basic hygiene ...
>
> I propose the following guideline: If you have a target that generates
> A (and B as a side-effect), then a 'clean*' rule that deletes B should
> also delete A (and vice versa).
>
> So, I do have a rule to delete *.d files, it's called "clean".
Since
> I don't have rules for building .d files other than with .o files,
it
> Just Works.
>
>
> >> or rename it to the more accurate "break-future-builds".
> >
> > If you have a sensible rule to generate .d files when needed,
you
> > haven't broken your builds - you've just obliged yourself to
> > regenerate .d files. Which may be wasteful, but see below.
>
> Okay, so if you have a rule to delete .d files without deleting .o
> files, you need rules to build .d files. In my experience, the
only
> reason to have *either* of those is "because that's how the Makefile
> was originally written and the current behavior doesn't hurt enough
> for me to spend the time to fix it".
>
>
> ...
> > 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. So make will not even try to compile anything
(even
> > though everything *would* compile fine) because your .d file
say that
> > all the .o files that need recompiled depend on a file that doesn't
> > exist any more; make clean-depend fixes that.
>
> The fix for that has been documented for years on Paul's webpage,
and
> is most easily done now with gcc's -MP option.
>
This is also kind of the solution I would have used
(kinda, as I would just have made a %.h rule), but then the gcc manual
is a bit confusing, as it mentions phony targets (which would really break
the idea of incremental builds), but I see that the targets are only phony
in the English sense, and not in the GNU Make sense (.PHONY).
>
> > If generating .d as a side-effect, don't listen to the manual's
advice
> > that says you need to sed its content to claim that the .d depends
on
> > the same things the .o does. If those things have changed,
the .o
> > shall be regenerated and hence so shall the .d; and you don't
need
> > this updated version of the .d file to discover that the .o needs
> > rebuilt. Changes to .h files consequently never trigger
re-exec.
>
> Ah, it looks like your comments are addressed at just what's in the
> GNU make info pages and not the advanced method on Paul's webpage.
I
> agree that what's in the info pages has many of the problems you
> mention...which is why this thread is about updating what's there.
>
>
> Philip Guenther
>
[Prev in Thread]
Current Thread
[Next in Thread]
Re: Shorter and less error-prone rule for automatic prerequisite generation in the GNU Make manual,
Robert Jørgensgaard Engdahl<=