This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: #include_next and removing of duplicate include dirs
- To: 'Jakub Jelinek' <jakub at redhat dot com>, Zack Weinberg <zackw at panix dot com>
- Subject: RE: #include_next and removing of duplicate include dirs
- From: Bernard Dautrevaux <Dautrevaux at microprocess dot com>
- Date: Tue, 4 Sep 2001 09:53:05 +0200
- Cc: Nathan Sidwell <nathan at codesourcery dot com>, Neil Booth <neil at daikokuya dot demon dot co dot uk>, Benjamin Kosnik <bkoz at redhat dot com>, gcc at gcc dot gnu dot org
> -----Original Message-----
> From: Jakub Jelinek [mailto:jakub@redhat.com]
> Sent: Monday, September 03, 2001 6:57 PM
> To: Zack Weinberg
> Cc: Nathan Sidwell; Neil Booth; Benjamin Kosnik; gcc@gcc.gnu.org
> 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 <nathan@codesourcery.com>
> > >
> > > * 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
foo/xxx
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
scheme.
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.
Regards,
Bernard
--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel: +33 (0) 1 47 68 80 80
Fax: +33 (0) 1 47 88 97 85
e-mail: dautrevaux@microprocess.com
b.dautrevaux@usa.net
--------------------------------------------