This is the mail archive of the gcc-patches@gcc.gnu.org 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]
Other format: [Raw text]

Re: header search path change with 2003-03-02 commit


Answering slightly out of order.

On Tue, Mar 25, 2003 at 07:30:56PM +1030, Alan Modra wrote:
> >  Why should the iprefixed directories come first (again,
> > please add a comment too)?
> 
> It's easy to see that each individual iprefix dir should come before
> its untranslated dir.  I can't explain why all the iprefix dirs should
> come before any other dir, except that this was the behaviour prior
> to Daniel's patch.  Perhaps someone uses iprefix in combination with
> #include_next.

This was the behaviour prior to my patch.  However I think that it was
wrong.  How about this - it's a bit of a change from the way we used to
work, but...:
  - Build the translated pathname.
  - If the directory exists (stat) use it.
  - Otherwise use the untranslated pathname.

Then we get them in the right order.  For example /usr/local/include
before cpp_GCC_INCLUDE_DIR/include.

> On Tue, Mar 25, 2003 at 06:44:20AM +0000, Neil Booth wrote:
> > Can you explain why you avoid the sysroot stuff here (and also add it
> > as a comment)?
> 
> Because Daniel wants it that way? :)  I don't really have a good
> reason, and if anything I'd say iprefix _should_ affect the sysroot
> paths.  ie. I think the first pass over the include dirs should do
> 
> 	  if ((!p->cplusplus || cxx_stdinc)
> 	      && !strncmp (p->fname, cpp_GCC_INCLUDE_DIR, len))
> 	    {
> 	      char *str;
> 
> 	      str = concat (iprefix, p->fname + len, NULL);
> 	      if (sysroot && p->add_sysroot)
> 		str = concat (sysroot, str, NULL);
> 	      add_path (str, SYSTEM, p->cxx_aware);
> 	    }
> 
> That way iprefix affects the standard paths within the sysrooted
> tree.  Seems least surprising to me.


> > How many of the paths in cpp_include_defaults can begin with
> > cpp_GCC_INCLUDE_DIR?  Can it be more than one?
> 
> I've seen two.  $prefix/$target/sys-include and
> $prefix/$target/include.

Hooold on a second.  $prefix/$target has nothing to do with
cpp_GCC_INCLUDE_DIR.  It's normally "$(libsubdir)/include" minus the
last eight characters ("/include").  There shouldn't be more than the
one include directory there normally.

Similarly I can't think of a meaningful configuration where
$(libsubdir) will end up at the beginning of any sysrooted dir; the
sysrooted dirs are only for LOCAL_INCLUDE_DIR and STANDARD_INCLUDE_DIR.
Arguably some of the C++ dirs also should be.

cpp_GCC_INCLUDE_DIR-prefixed directories should always be mutually exclusive
from sysrooted directories.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


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