[distcc] small protocol extensions for -ftest-coverage, -fbranch-probabilities

[Martin Pool]

On 25 Jun 2004, Daniel Kegel <dank at kegel.com> wrote:
> Martin Pool wrote:
> >Yes, one thing I wanted to do was to allow the client to control the
> >input and output filenames, which implies a clean directory for each
> >job.
> 
> Yup.  Should the client have to specify which files it wants
> back, or should the server just send back everything new?

It's a tough call.  I think the client should ask for the ones it
wants.  Some tasks generate large uninteresting output files.
(distlatex?)

A neat feature of this is that the client can simply send

  gcc -dumpversion

with no input or output files, to make sure the versions are the same.

> >>(And I have to patch gcc anyway to set the directory name used for
> >>the .da files.  Maybe I could get away with combining the two, but I
> >>don't think so.)
> >
> >
> >Could you explain more about this?
> 
> When you run a program compiled with -fprofile-arcs, it creates a
> .da file in the directory the original source file lived in,
> with a filename the same as the original source file but with
> a different suffix.  I think the right way to deal with
> this for distcc is to add an option to gcc to use
> as the directory for creating .da files, and to change distcc to preserve 
> the
> original source filename when making the .i (changing the suffix, of 
> course).
> Then the distcc client could use the new option to pass the
> cwd of the original source file to the compiler regardless
> of how many source files are sent across for compilation.

Alexandre had a plan to put the source directory into the .i file to
fix the debug symbols.  Maybe this should ride on that?  

> (Heh.  Notice my nefarious plan to eventually speed things
> up and allow whole-program optimization by sending across
> multiple .i files to the remote compiler in one request someday?)

The only flexibility missing from protocol-3, I think, is jobs that
need to have files operated upon by several successive commands.  So
you'd need to have a way to leave some files on the remote machine so
they can be seen by the next job, but to keep them seperate from other
users.  That might be needed for compiling Java: the compiler needs
all the class files, but you wouldn't want to transmit them anytime.
I think it's OK to hold that over until protocol 4.

--
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.samba.org/archive/distcc/attachments/20040626/2d8166c0/attachment.bin