[distcc] Re: implicit compiler name

[Martin Pool]

On 16 Sep 2002, Alexandre Oliva <oliva at lsd.ic.unicamp.br> wrote:
> On Sep 16, 2002, Dimitri PAPADOPOULOS-ORFANOS <papadopo at shfj.cea.fr> wrote:
> 
> > Then there would still be the option of letting distcc run the
> > compiler the name of which is given by the symlink. This way
> > you don't have to modify Makefiles and you can easily switch
> > between a GNU compiler and a native compiler:
> > 	CC  -> distcc CC
> > 	g++ -> distcc g++
> 
> But then, again, it's not that simple.
> 
> Consider PATH=/usr/local/ccache/bin:/usr/local/distcc/bin:/usr/bin:...
> such that:
> 
> /usr/local/ccache/bin/gcc -> ccache
> /usr/local/distcc/bin/gcc -> distcc
> /usr/local/bin/gcc is the real thing
> 
> distcc has to be smart enough not only to know that the real gcc is
> looking for has to be different from a link to itself, but also that
> it must be *after* itself in the PATH, otherwise running gcc will
> enter infinite recursion between ccache and distcc.

Having recently seen this wierdness in Linux 2.2.21, I am starting to
like the symlink idea as a way of handling existing makefiles.

  http://distcc.samba.org/problems.html#linux2.2q

On the other hand, many existing makefiles may have race conditions
that will break parallel builds, or at least builds with high degrees
of parallelism.  So perhaps total compatibility with existing
Makefiles is an unrealistic goal.

On Debian, we have
 
  /usr/bin/cc -> /etc/alternatives/cc
  /etc/alternatives/cc -> /usr/bin/gcc
  /usr/bin/gcc -> gcc-2.95

So checking symlinks to find out which is the real compiler may be a
bit hard.  

It's also not uncommon for machines to end up with different programs
installed in /usr/bin and /usr/local/bin, so there may be two copies
of distcc on the path.

-- 
Martin