[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