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. __ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/cgi-bin/mailman/listinfo/distcc
