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

[Martin Pool]

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

Hi Wayne,

There are some notes about this in the TODO and other documents in CVS
HEAD.

> I've been using distcc quite a bit lately because I've been playing
> around with gentoo linux (and having a compile farm is the one thing
> that makes the compiling of larger packages happen in a reasonable
> amount of time on gentoo). Why disguise distcc as gcc (etc.)? I've
> noticed several packages that do not honor the setting of CC or mess
> up if it is set to something weird. 

My overall feeling on this kind of issue is that it's good to make
distcc "plug and play", but only within reason.  It's not worth
twisting distcc into knots to work with particular wierd Makefiles.
Makefiles can be fixed.  It's hard to remove shipped features.

But this approach and patch look pretty good.  It's more or less what
I was heading towards.

> I'm currently using the gentoo
> wrapper setup that was previously mentioned on this list, but I'd like
> to see something cleaner -- something that could be implemented for
> all compiler-munging packages (distcc, ccache, etc.) and would let
> each user choose what to use and in what order to use it.

Yes.  The gentoo wrapper (before the current one) I have to say didn't
look good

 - only configurable by root
 - hella messy code
 - very gentoo-specific

You need to also take into account the danger of the daemon getting
one of the wrappers onto its PATH.  For things started from init.d it
will be enough to just reset the path from the ctl script, but for
things started interactively it's a problem.  1.1 will flag this as an
error, but not avoid it.

I've been holding off doing something like this because I want to make
sure that the potential confusion caused by interceptors is
justified.

> PATH=/usr/lib/ccache:/usr/lib/colorgcc:/usr/lib/distcc:/usr/bin:/bin

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

>    http://www.clari.net/~wayne/wrapper.patch

I would probably factor it out a bit before merging.

I've been hesitant to check argv[0]=='distcc', because it can lead to
confusing behaviour if people rename it to, say, 'distcc.old' or
'distcc-1.1'.  I guess it's probably OK.

We would need to either ship the libiberty alloca() or call something
else.

If this is merged then some of the code in implicit.c ought to change
to use am_distcc.

It needs documentation and tests or a test plan -- not that I mind you
not posting one at this early stage.

So does everything in gentoo build with this?  If not, what other
problems are there?

Thanks,
-- 
Martin 

Our policy is, when in doubt, do the right thing.
		-- Roy L Ash