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

[Wayne Davison]

On Tue, Feb 04, 2003 at 11:54:51AM +1100, Martin Pool wrote:
> You need to also take into account the danger of the daemon getting
> one of the wrappers onto its PATH.

Yes, this is a danger.  One solution might be to have an environment
variable like DISTCCD_PATH that would override the path when the user
runs distccd.  However, the user would still need to remember to set
this in a shell rc file somewhere.  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.

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

Yeah.  I did a quick scan, but didn't have time to do a thorough search
yet.  Perhaps /usr/lib/distcc/bin would be a better choice than
/usr/lib/distcc, for instance.  I did notice that they specify that /bin
must not contain subdirs, but they don't say anything about /usr/bin.
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 (I don't like how in gentoo has /usr/bin/ccache as a subdir and
puts the executable inside -- yick).

> 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'.

Perhaps a prefix-test would be better, where we honor the distcc options
for anything that begins with the string "distcc".  This handles at
least some of the potential failure cases (and lets the user keep
multiple distcc programs around, if desired for some reason).

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

What I did (in my first-cut patch) is to just to avoid calling
dcc_find_compiler() if am_distcc is true.  I did notice that it is also
called from some test code, but I did not try to deal with that.  I
almost passed a flag and argv[0] down to dcc_find_compiler() and let it
do the right thing to construct the list, but I wanted to make the patch
apply small and easy rather than to be designed right (at this stage),
just to see if you liked the idea.  I'd be glad to do a better patch if
you like the general idea (and work on the docs too).

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

I have been starting with a stage3 tar, so most of the system is already
built.  However, I've compiled some 75 gentoo packages (such as perl,
gdb, python, screen, vim, zsh, etc.) with a distcc wrapper with no
failures yet (I have only compiled a handful with my new distcc-based
wrapper, but the concept is the same).  I'm sure there are some gotchas
lurking out there somewhere, but I haven't tried some of the really hard
things yet (such as compiling KDE -- maybe soon) so I'll run into them
eventually and let you know what I discover.

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).  The other weird thing is that sometimes
ccache appears to punt the command without doing anything in cases where
I think it should be doing something (but I haven't tried to figure that
out that yet either, and that's a ccache thing anyway).

..wayne..