[distcc] Re: issue fix proposal for distcc and intel C++ 7.1

[Martin Pool]

On  9 Jul 2003, Markus Werle <numerical.simulation at web.de> wrote:
> Martin Pool wrote:
> 
> > > Yes, and it can also be controlled by --verbose and --debug like for
> > > many UNIX tools around the world ;-)
> >
> > Yes, if distcc were going to handle command line options then those
> > would make sense.  However, for reasons Wayne already discussed,
> > except for --help and --version distcc treats all options as being
> > compiler options, not distcc options.  I think this is the course that
> > gives best compatibility.
> 
> I already showed in this thread that it is quite simple to
> just use the convention that only args after
> 
> The reasons Wayne discussed can all be resolved easily except one,
> for which I propose a workaround.

Experience to date seems to show that putting some configuration in
environment varaibles and/or files is the only way to make many
existing projects build.  This is unfortunate but unavoidable.

> > a space-containing $CC value does not always
> > work with all projects, 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
> 
> I consider such a build system as exception (or broken system)

Yes, I think it's broken too!  But, as I think you said earlier,
sometimes we need to make concessions for brokenness.

> So I accept that these systems need a workaround, but I disagree that the
> workaround should affect "normal" systems like simple linux+make.
> I still think that it is best practice to use command-line reading
> for control.

Environment variables must be supported.  Is it worth introducing a
second mechanism that can achieve the same effect?

The benefit seems to be mainly that parameters are a bit easier to
understand.  They are not much more concise or efficient.  And after
all, environment variables are already extensively used in the unix
toolchain, so the user audience ought to have at least a little
familiarity with them.

Adding a second way to configure it would mean more documentation and
more potential confusion.  There is enough of that already with the
implicit/explicit/masqueraded modes, and I don't really want to add
more without a compelling reason.

Is the problem that you want to be able to put things like
--extra-remote-cflags into the CFLAGS line of your Makefile?


> How about this: The script for the broken systems reads in all those
> environment vars and translates them to runtime args for distcc,
> while distcc itself gets rid of environment dependency and uses
> command-line parsing as proposed for unbroken systems.
> 
> Like this we get maximum flexibility for the unbroken _and_ the broken systems:
> If on system foo compiler bar needs some other flag to achieve -xc++,
> e.g. it needs -Xc++, this is no longer a problem:
> 
> On unbroken system we call
> make CXX="distcc --extra-remote-cflags=\"-Xc++\" --compiler=bar -O2 -g HelloWorld.C"

I think your quoting is wrong there.

Treating everything after --compiler as a compiler option is a bit
problematic because Makefiles can build up cc invocations in fairly
random order when combining CPPFLAGS, CFLAGS, and other variables.  I
think depending on the overall order is likely to cause trouble.  To
make sure that the --compiler option gets into the right place you
might need to put it into $CXX, which takes us right back to the
problem of that variable containing spaces (and indeed now '"' and
'=').

> while on broken systems we rely on a symbolic link
> /opt/distcc-2.9.1/bin/cc -> /opt/distcc-2.9.1/bin/wrap_distcc.sh
> This is why I propose command-line flag  --extra-remote-cflags

I would be willing to add a DISTCC_EXTRA_REMOTE_FLAGS setting.

-- 
Martin