DJ Delorie <[EMAIL PROTECTED]> writes:

>> and (c) whether or not you would be willing to trade that much
>> additional delay in an edit-compile-debug cycle for not having to
>> write dependencies manually anymore.
>
> Are there any compromise solutions?

Lots.

The program as it currently exists is quite stupid.  The biggest
optimization in real use would be to record file timestamps and not
recalculate dependencies for unchanged files.  This doesn't apply to
the cold-start scenario, of course.  How to do that is in question -
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.

Beyond that, cpplib internally could be made more efficient for this
task.  A simple thing you can do:

sed -e ':b; /\\$/{; N; s/ *\\\n */ /; bb; }' depend | 
  while read targ rest; do
    printf "%s " $targ
    echo $rest | tr ' ' '\n' | sort | uniq -d | tr '\n' ' '
    echo
  done

This prints, for every source file, the set of all header files that
appear more than once in its dependency list.  Each of these
represents a case in which the multiple-include optimization is
failing.  You will see that for many files the set is large; fixing
this should speed the calculation up noticeably.  Unfortunately, it's
going to be very hard to fix, because of the horribly complicated
semantics that we have accreted for #include.

There are other optimizations possible - we could avoid allocating
tokens in no-output mode, for instance - but I don't think they're
going to be as significant.

It should be mentioned that I do not have a solution for the problem
of automatically generated headers, and until I do, it's not going to
be feasible to turn this on.  (Note that, e.g. insn-config.h is
completely missing from the dependencies this program generates.)

A procedural approach is also possible, where the dependency lists are
checked into CVS but autogenerated by some method.  This would avoid
the time cost for most people and still get us more accurate
dependency lists, but I think people would still forget to update them
when they change the .c files so I'm not enthusiastic about this idea.

zw

Reply via email to