[distcc] using distcc to speed up gcc bootstraps

[Martin Pool]

On 14 Aug 2002, Alexandre Oliva <aoliva@redhat.com> wrote:
> A while ago, we've been talking about using distcc to speed up gcc
> bootstraps.  I've made some progress today towards this goal, but
> there's still some way to go to get there.

Great!

> - the bootstrap check fails, even though I have every reason to
>   believe it bootstrapped correctly.  I believe the cause of the
>   failure is the problem documented in distcc's manual: that gcc adds
>   the preprocessed filename to the debugging info emitted for each
>   file.  I believe it shouldn't do this, but rather just use the name
>   in the first #line directive in the preprocessed file.  I'll look
>   into trying to fix this problem, if I confirm it is indeed the
>   reason for the failure.

I can see how including the pwd is useful for making gdb more
friendly, but it seems kind of tacky at the same time, by putting a
kind of "hidden variable" into the .o file.  

If you have to do it, it seems to me that it would be cleaner to make
cpp resolve the absolute path of the input file, and put that in to a
# directive, either replacing the existing ones or otherwise.

Presumably you could also sometimes get false failures of other tools
that try to compare .o files built at different times.

> - the load on my build machine skyrockets while building the ada
>   compiler and the Java library.  It would be nice if distcc could
>   throttle other instances thereof when it realizes it can't send
>   builds to remote build servers.  A lock on localhost, to be used in
>   such situations, would be ideal IMO.  Is this an acceptable change
>   for distcc?

Yes, I think that would be very appropriate.  I would also like to
make it take into account the load caused by jobs which turn out to be
impossible to distribute, such as preprocessor or linker invocations.
I have started on that for the next version.

-- 
Martin