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

Markus Werle numerical.simulation at web.de
Mon Jul 7 09:05:32 GMT 2003

Martin Pool wrote:

> Now that hosts can be taken from a file, it shouldn't be necesary to
> set any variables in most cases.

how about

make CC="distcc --verbose --hosts=\"mach:9999 sylvie:9999\" --disable-fallback  --compiler=icpc"

instead of

export DISTCC_HOSTS=mach:9999 sylvie:9999 hooke:9999 localhost
make CC="disctcc icpc"

> I'm open to storing more things in files, but that has the
> disadvantage that you cannot use different settings for different
> builds, which is sometimes useful.

Option "-f" at hand:

make CC="distcc -f ./config_file_for_icpc"

I'd prefer no default filename, so no accidents occur in wrong
environments. If you forget you get an error.

> > > Doing so would make distcc explicitly depend on gcc and similar
> > > compilers, but in truth it is close to doing so already, and it would
> > > be possible to add modes for other compilers.
> >
> > Sorry I do not understand this.
> > Do you want to say:
> >
> > 1. distcc depends on gcc
> > 2. distcc should become compiler independent
> I meant that the "definition tables" should be only on the client
> side, whether they are expressed in C or in a data file.  The request
> to the server should just pass the command and input file, and the
> command should have already been completely transformed.  To be
> specific, at the moment arg.c is required by both the client and
> server.

I see. And I agree.

> > The problem here is GNU autotools.
> > automake/configure has problems which I could not resolve.
> > Putting -xc++ into CFLAGS or CXXFLAGS makes linkage fail,
> > since these are also included in the linker call.
> > -xc++ during linkage makes icpc think the object file is C++
> > which gives some funny syntax error messages :-)
> What a mess.

Yes. Getting really fed up by now.

> OK, I'll see what I can do.

Many thanks.


More information about the distcc mailing list