Re: -I/usr/include

[Nathan Sidwell <nathan at codesourcery dot com>]

"Joseph S. Myers" wrote:
> It's already documented in gcc.texi that you shouldn't do that, but the
> documentation tries to tell you how to do it anyway (and is very out of
> date, referencing /usr/local/lib/g++-include).  So, at least change the
> documentation to say "don't do that", without trying to tell people
> exactly what directories to include manually.  (The include search paths
> should be documented, but not there; if someone wants to handle the
> include path manually they should be using -nostdinc -isystem and know
> what they're doing.)

What I forsee when 3.0[*] is deployed is people doing what I
did for random package
	configure
	make
	*bang*
If I'd got a nice big warning saying
	'don't do `-I/usr/include''
rather than eight million confusing diagnostics, it would've been more
obvious. [in this particular case, it was unintentional that configure created
a -I/usr/include]

Perhaps what is needed is that when inserting a -I directory into the search
path, we check to see if the directory is already known later on down the
list, and if so issue a diagnostic such as
	warning, changing search order for `dir'
this is especially true if we're moving a directory into the user search
path which already exists in the system search path.

thoughts?

nathan

[*] g++ 3.0 & stl is _much_ more sensitive to this than 2.95
-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org