[distcc] where does preprocessing take place

[Martin Pool]

On 30 Jan 2005, Jean Delvare <khali at linux-fr.org> wrote:
> Hi Martin,
> 
> > > Why do we decide which remote host will get the compilation *before*
> > > preprocessing is finished, rather than after? Different machines may
> > > be available by the time the preprocessing is finished. Looks clear
> > > to me that the current model forces the chosen remote machine to be
> > > idle during local preprocessing. By doing it the other way around,
> > > wouldn't we make a better use of the various available remote
> > > machines (unless local preprocessing has become the bottleneck
> > > already)?
> > > 
> > > Just a question of course, maybe there are reasons why we wouldn't
> > > win anything in doing so, that I didn't see.
> > 
> > We need to decide whether to do it locally or remotely to know whether
> > to preprocess separately or not.
> 
> We don't really have to. We could always preprocess it separately, and
> wonder what to do with it afterwards. If it's for localhost, it still
> works, just that it could have been faster. Maybe there would be more
> gain than loss in doing so?

Using the separate preprocessor for localhost may be a substantial
loss, because gcc won't be able to use the integrated preprocessor.
It might be worth trying though -- it shoul dbe an easy change.

> > We could first decide whether to do it on localhost, then preprocess
> > if not, then choose the particular remote machine.  That would be
> > somewhat superior as you say.
> 
> Now that I think on it... In the remote compilation case, aren't we
> passing the preprocessed data to the distant host on the fly as we
> generate it? If this is the case it explains why the host has to be
> chose before, and voids all my complaints (in which case I am sorry for
> the noise). If not, what I said probably remains valid and could be
> explored.

No, the preprocessor completes before any data is sent.

-- 
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/20050131/d12cf7ab/attachment-0001.bin