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

[Martin Pool]

On  7 Jul 2003, Markus Werle <numerical.simulation at web.de> wrote:

> As quick solution this is OK.
> 
> I'd rather prefer a generic solution. I believe every compiler has this or a
> similar feature, namely tell the compiler to eat the file as C/C++ code,
> disregarding any file extension.
> 
> So better have either some environment variable, some command line flag
> or some configuration file input handle this.
> Best practice is a command-line+config file input _and_
> automatic dispatch for known compilers (version specific).

Yes, that probably makes sense.

A table driven system will be a bit complex, because the interactions
between the different compiler options are complex.

It may make more sense to do that in a higher-level tool that builds
on top of distcc.  One called ccontrol is already underway but not yet
released.

> Due to rising complexity distcc really is in need need to use some
> command-line tool (like good old  lex/yacc?)
> and a struct containing char* reached through to all functions
> such that all apects of program behaviour can be handled
> in all these functions.
> 
> struct runtime_behaviour
> {
>     char* compiler;
>     char* compilation_flages;
>     char* linker_flags;
>     /* etc */
> };
> 
> Search sourceforge.net for nice tools which handle this.
> 

> The code looks like all those environment vars are just there in
> order to circumvent the command line reading, but letting users set
> ENV is annoying. Rather get window-independent.

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

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.

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

> 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.  OK, I'll see what I can do.

-- 
Martin