[distcc] gcc bootstraps with distcc

Neil Booth neil at daikokuya.co.uk
Fri Jul 11 22:07:56 GMT 2003


Alexandre Oliva wrote:-

> >> +      _cpp_do_file_change (pfile, LC_RENAME, dir_with_slashes, 1, 0);
> >> +      _cpp_do_file_change (pfile, LC_RENAME, name, 1, 0);
> >> +    }
> 
> > Is the second rename necessary?  I don't see why it should be;
> > if not let's not do it.
> 
> AFAICT, yes.  Without it, -E -fpreprocessed is not equivalent to
> `cat'.

<builtin-in> doesn't do this; you used to cite <built-in> as precedent
for what you do.

> > This is really horrible.  cb.dir_change should return void, things about
> > "too late" are no concern of cpplib.
> 
> So, no error if one tries to set it more than once?  No error if it's
> set too late?  Or just print the error elsewhere, and not let cpplib
> know about it?

cpplib is a library.  It couldn't care less if the client has a problem.
Debug output is a client-specific issue.  We're talking about a cpplib
feature, and so a specific client error is obviously out of place in cpplib.

Do you tell cpplib to report if the compiler meets an invalid tree node?

> >> - %{M} %{MM} %{MF*} %{MG} %{MP} %{MQ*} %{MT*}\
> >> + %{M} %{MM} %{MF*} %{MG} %{MP} %{Mpwd} %{MQ*} %{MT*}\
> 
> > Is there a good reason for this?  If not, let's go with -fpwd as
> > default and -fno-pwd.
> 
> Hmm...  I'm thinking the internal cpp option for this should be not
> -gpwd, but rather -dP, since it affects the preprocessor's output like
> other -d options.  We would then use %{!gno-pwd:%{g*:-dD}} in the
> preprocessor's spec.

What do you mean "internal cpp option"?  Why do you insist on unnecessary
complexity?  Why do you want to change specs at all?

This whole thing is a cpplib feature for which debug output is
orthogonal - it just happens to be the use that this client puts the
feature to.  -gpwd and -gno-pwd therefore, whilst better than -M stuff,
are not ideal.  -fpwd has builtin-in support for the negative, is
forwarded to CPP automically, and is therefore the clear choice.
No spec changes necessary.

Neil.



More information about the distcc mailing list