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

[Markus Werle]

Martin Pool wrote:

> On  1 Jul 2003, Markus Werle <numerical.simulation at web.de> wrote:
> > Hi!
> >
> > After struggling a lot with the C programming language
> > (yes, I am a pure C++ programmer and I think by now that
> > these  two languages have nothing in common), I finally found a
> > solution that makes intel C++, distcc _and_ autotools happy
> > at once.
> >
> > I introduced a new environment variable
> > DISTCC_ADDITIONAL_REMOTE_COMPILER_FLAGS
> > which I set to "-xc++"
>
> [cc'd to list]
>
> Alternatively, distcc could just *always* generate the appropriate -x
> option depending on the input filename.   -x is supported since gcc
> 2.95 at least.

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

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.

There should also be a compiler specific setup routine which sets
extra flags for remote calls:

// c++
if ((compilername == "icpc") || (compilername == "icc"))
{
   REMOTE_ADDITIONAL_CFLAGS += "-xc++ ";
}

> Doing so would remove the need for the server to set the extension of
> the temporary filename.

Yes.

> That would be quite nice, because in the long
> term I would like to move gcc-specific heuristics out of the server
> into only the client.

I'd prefer moving compiler specifics into extra file
which cam quickly be adopted by developers/users.

> 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

?


[ copied from private email since it belongs here, too]:

Martin Pool wrote:

> Thanks for your efforts in researching this!

>  The -x option does look like the right way to fix it.

>  I wonder if it would work just as well to set CFLAGS='-xc++' at the
>  top level, rather than having distcc add it when running the remote
>  compiler.  Is it OK to have this option when preprocessing and
>  linking?

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 :-)

Putting it into CPPFLAGS had other problems I do not remember
anymore. I feel like distcc should handle this itself.


best regards,


Markus