[distcc] gcc bootstraps with distcc

[Alexandre Oliva]

On Jul  2, 2003, Neil Booth <neil at daikokuya.co.uk> wrote:

>> source and build trees.  The reasons -Mpwd is not enabled by default
>> are backward compatibility (the <directory> directive might be
>> unexpected, even though it's in a format that is entirely
>> backward-compatible), efficiency and to enable ccache caches to be
>> shared by multiple build trees.

> Ignoring the other two, is this last reason a good reason still for
> it not to be default?

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.

> I don't like this.  If we're going to do this directory thing, and I
> don't see why not if it's useful, we should provide a separate
> callback and not overload this one (which is hairy enough as-is).

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?

> My above suggestion would thankfully lose most of this, no?

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.

> Can you give me some time to think about where this information is
> stored?

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.


Thanks for taking the time to go through this once again.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer