Re: PATCH: cpp include directory search order warning

[Zack Weinberg <zack at codesourcery dot com>]

On Wed, Aug 07, 2002 at 12:48:48PM -0400, John David Anglin wrote:
> Here is a fix for the problems noted in this thread:
> 
> <http://gcc.gnu.org/ml/gcc/2002-07/msg01463.html>.
> 
> The warning from remove_dup_dirs is changed to an information message
> generated only when the "-v" option is used.  This allows various
> autoconf macros to reorder the search patch for includes and change
> system directories to non-system directories without any warnings from
> the preprocessor.  This will fix the problems caused by the warning.
> However, don't complain to me about an incorrectly ordered include
> search :-)
> 
> Without the fix, it is not possible to install libintl, libiconv,
> etc in either the GCC prefix or local_prefix directories without
> there being cpp warnings building packages which use these libraries.
> In some cases, these warnings break configure scripts.

As I said in the previous thread, I don't want to make _any_ changes
to the current behavior until we have consensus from all people
involved that the change is correct.  I'm not even convinced that we
know the scope of the problem.  I would prefer that all involved spend
time doing research into that, _before_ we start tossing patches
around.  We've had several cases come up where the current behavior is
a problem; we've had some handwaving around why -I /usr/include is a
bad idea; that's not nearly exhaustive yet.

The original patch introducing this warning was written by Nathan
Sidwell.  I would like to get his input.  Last time I tried to contact
him on this, the mail bounced; here's trying again.

> The change to configure.in just fixes a minor problem of duplicated
> directories when local_prefix and prefix have the same value.

This change is independent of the warning issue; go ahead and check it
in now.

> I have attempted to summarize the site configuration issues regarding
> include searching and library searching in a paragraph added to
> install.texi.

This is very helpful, thank you.  I see some typos in the text -
please check and correct these.

> +Some autoconf macros use @option{-I} to change the
> +search order for directories containing installed packages.  This can
> +result in a GCC system directory being changed to a non-system directory.

I believe it is more accurate to say that

  Some autoconf macros add @option{-I @var{directory}} options to the
  compiler command line, to ensure that directories containing
  installed packages' headers are searched.  When @var{directory} is
  one of GCC's "system include" directories, this will cause it to
  be treated as a non-system directory.

Note the intent of the autoconf macro in putting the -I option on the
command line.  Not to tweak the search order - just to make sure that
package headers get found.  This raises an alternate possibility for
solving the problem: When we see -I <dir> where <dir> is already on
the default include path, ignore the -I option (give notice of this
under -v).  If the default include path is suppressed by -nostdinc,
then this naturally does not happen.

Would that treatment work in your environment, John?  Anyone else have
an opinion?

zw