On Jul 2, 2003, Neil Booth <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED], gcc.gnu.org} CS PhD student at IC-Unicamp [EMAIL PROTECTED], gnu.org} Free Software Evangelist Professional serial bug killer __ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/cgi-bin/mailman/listinfo/distcc
