[distcc] Re: distcc control methods

[Markus Werle]

Wayne Davison wrote:

> On Mon, Jul 07, 2003 at 11:05:32AM +0200, Markus Werle wrote:
> > make CC="distcc --verbose --hosts=\"mach:9999 sylvie:9999\" --disable-fallback --compiler=icpc"
>
> This has a potential problem of when to stop parsing distcc options and
> when to start parsing compiler options (since the build's command-line
> is just appended to this).  You'd have to either add an end-of-distcc-
> options marker (like a trailing "--"), or perhaps require that the
> --compiler option always be specified as the last option to distcc.

OK, let us specify that _any_ command line option after
--compiler=<compiler> is reached through to the compiler without
further modification. No problem for the parser (sorry, for _my_ C++ parser,
which I'd share with you if you do not find a better one).

> Another problem is that a space-containing $CC value does not always
> work with all projects,

Could You give an example?

> and any $CC value at all may not be honored by
> some build setups.  Thus, for me, I never set CC and just add a distcc
> masquerade dir to my PATH (along with ccache):

>     PATH="/usr/lib/ccache/bin:/usr/lib/distcc/bin:$PATH" make
>
> In such a setup, there's no way to specify those command-line options to
> distcc.

I see the problem and a solution:
If You dislike setting CC, how about a shell script /opt/my_distcc/bin/cc
which calls
distcc --verbose --hosts=\"mach:9999\" --disable-fallback --compiler=icpc
and PATH=/opt/my_distcc/bin:$PATH

> An alternative would be to have a control program that the user
> could run to setup how distcc will run.  For instance:
>
> distcc_control --verbose --hosts="mach:9999 sylvie:9999" --disable-fallback --default-compiler=icpc

My opinion is strongly against such a solution.

1. environment vars and default config files are like global variables.
I found that a little redesign can let you get rid of those
giving you more reliability and easier control.

2. A second tool that must be called with lasting side effects is
unnecessary. Runtime behaviour is always controllable through
command line args plus optional config file.
A program which leaves the environment changed after termination
is the worst case of all (IMHO)


> Then, if the user runs distcc_control without any options, they'd get
> a summary of how distcc was setup to run.

distcc --help
will present the defaults.

> The control program could
> either set environment variables or manipulate config-file settings in
> a config dir, depending on how Martin wants to make it controlled.

Martin, yes. I respond to him in a minute.
(CC'ed to this ML).

> If there is a change from the environment to files, it would have to be
> flexible enough to not assume that ~/.distcc was the dir to manipulate
> because the gentoo setup would not work well with this when HOME
> changes during an emerge compile.  E.g. I'd want root to manipulate the
> config in /etc/distcc, and the portage user to fallback to this config
> when there was no per-user config present in ~/.distcc.  I current use
> this method of choosing where the distcc hosts file should be stored
> (in my distcc_probe perl script that scans available hosts and
> manipulates the current host setup).

Which brings us to the question, why a user tool must have
config in /etc. This is unnecessary binding between the tool and the
system. Just too comlicated: note that this discussion started because
I wanted distcc to simply add some "-xc++" to remote calls.


Markus