[distcc] distcc in disguise (a suggestion for all "wrappers")

[Martin Pool]

On  3 Feb 2003, Wayne Davison <wayned at users.sourceforge.net> wrote:

> Another work-around is to have distccd set an environment variable
> that will cause distcc to punt the command down the PATH.  This
> means that compiles will work fine, just that they will exec (at
> least) one too many programs for each compile.  If such a thing were
> allowed to happen, it would be good to alert the user somehow that
> it was going on, so that they could optimize it.

That sounds pretty good.  At the moment it detects this and just
fails; but it could equally well punt to the next thing on the path.

> > We need to check where the FHS says these things should go.

FHS r2.2 (s4.1) forbids /usr/distcc.

The Gentoo solution of /usr/bin/distcc/cc is a bit ugly.

> If somewhere in /usr/bin is desired, I'd want to see it be something
> more like /usr/bin/distcc.links so that distcc could still go in
> /usr/bin

That sounds reasonable.

Speaking to cyeoh from the FSG it looks like either 

  /usr/bin/distcc.links/cc
  /usr/lib/distcc/bin/cc

> So far the only thing to report is that I have seen some strangeness in
> the number of processes that make creates -- it seems to sometimes
> create the asked-for number of distcc processes for some packages, and
> not as many for others.  I haven't tried to look to see why yet (since
> there might be a valid reason).  

Oh, by the way, scheduling is kind of broken in CVS because I'm in the
process of changing it.  Basically the first machine gets most of the
load.  It's fine in 1.1.

So the question I keep coming back to is: wouldn't it just be easier
to fix Makefiles that have cc hardcoded?  Gentoo already has the
ability to apply patches before building, and they could be pushed
upstream.

-- 
Martin