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
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.
Jakub