Each time I do a full prc-tools build, I get a 1.3 Mb
build log and sometimes I even look at it. (Building prc-tools means
building two binutilses, two GCCs, a GDB, and a few other bits and pieces.
Along the way you build four BFDs and six libiberties. So that log builds
up pretty quickly!)

At the moment, due to popular demand (three FreeBSD whiners :-)), I'm working
on making --enable-nls work properly. To be sure, there's a bug here in the
current top-level prc-tools, and I'm glad to be finally looking into it.

So I'm comparing the logs from builds with and without --with-included-gettext.
I look at the differences between successive builds regularly (all hail
tkdiff!), but these two (of course) differ from each other in different
places from the usual. And there's many more differences to look at
than usual, alas.

This means I'm studying different parts of the logs from usual. Here's a few
lines from tonight's builds:

Huh? What's that path from the end of August doing there? That build tree
is long since blown away -- each one is over half a gigabyte, so I nuke them
pretty quickly. So I look at the build logs from the last week, and they all
say 20020831, and sure enough that directory certainly hasn't existed
for a long time.

I last really compiled bucomm.c back in August when I switched ccache on.
One of ccache's big features over compilercache is that it doesn't give up
in the face of warnings. So that 20020831 directory doesn't really exist;
it's just that I'm getting the old stderr log from August. It's hard to
see how ccache could correct this without rerunning the compilation or
parsing the basic error format and guessing, so it's understandable; on
the other hand, the Web page does say

[ccache provides] exactly the same object files and exactly the same compiler
warnings that would be produced if you use the real compiler. The only way you
should be able to tell that you are using ccache is the speed.

Sure, the speed is great -- ten minutes instead of 40 with my machine on
this project -- but I've just learnt one grain of salt to apply to the warning
guarantees :-).

Sure, there's other lessons to be learnt here: like don't vary your paths when
you're trying to do repeatable builds (but some form of date convention is a
useful and commonly used way to stay sane) and don't use absolute paths (but
sometimes your tools will make them absolute whether you want it or not).