Re: request for timings - makedepend

[Zack Weinberg <zack at codesourcery dot com>]

DJ Delorie <dj@redhat.com> writes:

>> probably the sanest thing is to go with the automake-like approach of
>> one .d file per .c file, which then can be annotated without having to
>> write logic to parse a big dependency file and update it in place.
>
> The problem with .d files is that there's no good automatic way to
> deal with headers that get renamed or deleted; the dependency on the
> old file is listed but there's no way to make that file.

This is a problem with the monolithic dependency file, too.

> Although something in the back of my head says that gnu make knows how
> to deal with this now.

Not to my knowledge.  GCC's -MP is a workaround, which could be
implemented for this program too.

>> Beyond that, cpplib internally could be made more efficient for this
>> task.  A simple thing you can do:
>
> FYI libiberty has a dumb perl script that generates its dependencies.
> It's not as flexible as cpplib, but it makes assumptions that are safe
> to make because it knows how libiberty is coded.  It might be
> interesting to compare that script to libcpp to see if it hints at
> faster processing.

That script doesn't really parse the file at all, it just scans for
#include lines, and it processes each header only once no matter how
many files reference it.  Which has got to be faster than what cpplib
is doing.  Unfortunately, I'm not confident it's safe to make similar
assumptions for GCC's code (basically, that no #includes are guarded
by conditionals, and that you'll never see "#include" beginning in
column 1 inside a comment).  I suppose we could declare all violations
of that rule to be bugs...

zw