[distcc] gcc bootstraps with distcc

[Neil Booth]

Alexandre Oliva wrote:-

> I'm undecided.  People like to be able to share ccaches, despite the
> fact that, if they do, they'll end up visiting a different, shared
> source code base (which is generally fine, since, if there was a cache
> hit, the code is identical anyway).  However, we could argue for
> having it enabled by default, and disabled with a flag.  I was just
> trying to preserve as much of the status quo as possible.

OK, let's keep it non-default.

> Hmm...  Separate callback.  Sounds reasonable, even if a bit
> over-engineered to my taste.  I mean, if we have <built-in> and
> <command line>, why not go ahead with <directory> as well?  I do agree
> we should try to avoid the overhead of string comparison, though, so
> how about LC_DIRECTORY instead of LC_RENAME for this case?

The LC_ are for a clear purpose: they indicate change of file name;
yours doesn't do that.  It's completely orthogonal.  If you need more
convincing, the LC_ affect line maps; this directory stuff is unrelated.

There is a good reason for <built-in> and <command line>, namely
diagnostics.  If there are diagnostics referring to macros or
syntax errors from built-ins or the command line (including switches
-include and -imacros etc) their location will be reported as
<built-in> or, e.g. for -imacros, "in file included from /whatever/
included from <command-line>".  <directory> serves no such purpose.

However, preprocessing a .i file should continue to output its
input.  Does it?

> I'm afraid not.  We have to get the cwd directory right before we emit
> the very first bit of debugging info and, in some formats, it's the
> very first thing we emit, which is part of the reason for this
> cpp_read_main_file ugliness.  So we have to do it in
> cpp_read_main_file or in its caller.

I was referring to all the mucking about with text strings.  I don't
see why it would remain necessary.

> As long as something that fixes this long-standing issue can get into
> GCC 3.4 before it enters stage 2, sure :-) :-)
> 
> > I'm not sure if I prefer something like this, or perhaps
> > somehow storing it in the first #line.
> 
> I couldn't find a clean way to get it into the first #line.  Also,
> backward compatibility is relevant to a point.  Consider feeding a
> preprocessed file with -Mpwd (or with this enabled by default, which
> is how I had it at first) to a compiler that doesn't know how to
> handle a new line marker flag.  Comments, which you had suggested to
> me at the GCC Summit, were too tricky to get right, so I ended up
> sticking with the <directory> marker, based on the <built-in> and
> <command line> precedents.
> 
> The important point about using a compiler that may not understand the
> <directory> marker in preprocessed input is that distcc may actually
> run into such situations, if the compiler that preprocesses the code
> in the host machine happens to not be the same as the one that will
> compile the preprocessed code.  This will often fail for other
> reasons, but I'd rather not force it to fail by introducing an
> intentional incompatibility.  That's why I designed it the way I did.
> If you know nothing about <directory>, you'll probably just end up
> discarding that line.

Hmm.  OK; let me think about it.  As I point out above; <built-in>
and <command line> are not "precedents" in the way you appear to have
thought, but I don't have a better idea at the moment either.

Neil.