This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: #include_next and removing of duplicate include dirs

> -----Original Message-----
> From: Jakub Jelinek []
> Sent: Monday, September 03, 2001 6:57 PM
> To: Zack Weinberg
> Cc: Nathan Sidwell; Neil Booth; Benjamin Kosnik;
> Subject: Re: #include_next and removing of duplicate include dirs
> On Mon, Sep 03, 2001 at 12:34:57PM -0400, Zack Weinberg wrote:
> > On Mon, Sep 03, 2001 at 05:30:32PM +0100, Nathan Sidwell wrote:
> > >
> > > COMPILER_PATH should be being zapped by
> > > 2001-07-01  Nathan Sidwell  <>
> > > 
> > > 	* tlink.c (recompile_files): Remove COMPILER_PATH and
> > > 	LIBRARY_PATH from the environment.
> > > for this very reason. Oh, I see that's not on the 3.0 
> branch, mainline
> > > only.
> > 
> > It seems like a low-enough risk change, can we get it on 
> the branch for
> > 3.0.2?
> I hope so.
> Anyway, the current #include_next behaviour is surprising and 
> incompatible
> to the one in 2.95.x (which did not remove any dups).
> If I specify -Ifoo -Ibar -Ifoo -Ibaz on the command line and 
> some header in bar/
> does #include_next, it is strange if either some header in 
> baz is included
> or error signalled, eventhough the header exists in foo.
> IMHO implementing this would not slow things down if 2 search 
> paths were used.

I don't understand the *real* problem here: if I "#include_next <xxx>", in
an include file in bar/, then:

	either I'm named bar/xxx, so there is no xxx in foo/, 
		or I was #include_next'ed from foo/xxx 
		and I *don't* want to again include foo/xxx
	or I'm named bar/yyy, and I can #include <xxx> directly to get

I understand there could be *very* complicated cases where this may be
useful (for example when two include chains need to #include_next one from
foo/ to bar/ and the other one from bar/ to foo/) but I think it would be A
LOT better to fix the include chains rather than rely on such a complicated

Anyway removing dups in the search path could be done when searching for
files, instead of when invoking the preprocessor; an efficient scheme could
be when parsing the arguments to link duplicates to their first occurence,
then skipping directories that were already searched for a given
#include(_next) directive. We thus would get both the same behaviour as
previously and better performance.



Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]