Add -iquote support

[Zack Weinberg]

Mike Stump <mrs@apple.com> writes:

[...]

Thank you for the quick update.  The documentation could use a little
polishing but let's not do that now.

>>    and, as I said, a loud public announcement (suggest posting to
>>    gcc-announce).
>
> Can we wordsmith this after the main patch goes in? 

I want the announcement sent out before the patch goes in, and user
commentary received.

> If not, do you have anything you'd like in it?
>
> I'd just say something like:
>
>     -I- will be removed in gcc 3.5.  Users that want to object are
> invited to contact gcc@gcc.gnu.org.  -iquote is meant to replace the
> use of -I-.  See <insert html link to generated html doc and gcc
> patches discussion here> for details.

Needs more detail on what exactly is changing.  How does this sound?

  In GCC 3.5, we are considering replacing the -I- command line option
  with a new -iquote option.

  The -I- option had two effects.  It caused all -I switches earlier
  on the command line to be considered only for headers included with
  #include "file" (not #include <file>), and it disabled the normal
  behavior of searching the directory containing the current file for
  headers included with #include "file".

  The proposed -iquote option, by contrast, simply takes its argument
  as a directory to search for headers included with #include "file".
  The directory containing the current file is still searched first.
  There would no longer be any way to disable that behavior.

  We are considering this change because some of our users have asked
  us for a way to augment the set of directories searched for
  #include "file", without suppressing the directory containing the
  current file.  It is our belief that that suppression is not
  useful in practice, because it tends to break system headers.  We
  would like to hear whether this is true.

  Please send comments on this issue to <gcc@gcc.gnu.org>.

> And like the ChangeLog, I'm happy to write it and send it out, but I
> will not be putting my name on it, as I don't want to be associated
> with the removal of a feature a user might be using.  Whose names
> should I put on it?

Please don't be evading responsibility like this.  Nothing would have
happened if you hadn't brought up the issue.

zw