This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Fixinc and mvme328.h (2nd try)
- To: ddsinc09 at ix dot netcom dot com
- Subject: Re: Fixinc and mvme328.h (2nd try)
- From: Manfred Hollstein <manfred at s-direktnet dot de>
- Date: Mon, 25 Jan 1999 18:27:34 +0100 (MET)
- Cc: egcs at egcs dot cygnus dot com, law at cygnus dot com, robertlipe at usa dot net
- References: <11546.915788304@hurl.cygnus.com><13979.13087.166270.809322@sls5gj.stgl.sel.alcatel.de><369B788A.A0EEE5A2@datadesign.com><13979.31135.891261.272909@sls5gj.stgl.sel.alcatel.de><13980.26518.531798.590317@sls5gj.stgl.sel.alcatel.de><369CC04A.F26D49AF@datadesign.com><13983.3546.80714.612766@sls5gj.stgl.sel.alcatel.de><13984.32018.881755.844159@saturn.hollstein.net><34C4BE50.B25B8380@datadesign.com><13989.63295.585987.609277@sls5gj.stgl.sel.alcatel.de><13994.4154.920367.601894@saturn.hollstein.net><36AC8B61.81D654C6@datadesign.com>
- Reply-To: manfred at s-direktnet dot de
On Mon, 25 January 1999, 07:18:57, korb@datadesign.com wrote:
> Manfred Hollstein wrote:
> > Here's another test:
> >
> > 1. Create the two files "/usr/include/sys/mvme328.h" and "/usr/include/sys/m328sio.h"
> > 2. Call "gcc -c -H t.c" and you'll see:
> >
> > /usr/include/sys/mvme328.h
> > /usr/include/sys/m328sio.h
> >
> > [[...]]
> > 1225 open("/usr/include/sys/sys/m328sio.h", O_RDONLY) = -1 ENOENT
> > 1225 open("/tools/gnu/include/sys/m328sio.h", O_RDONLY) = -1 ENOENT
> > 1225 open("/tools/gnu/lib/gcc.../include/sys/m328sio.h", O_RDONLY) = -1 ENOENT
> > 1225 open("/usr/include/sys/m328sio.h", O_RDONLY) = 5
> >
> > This is indicating, that your assumption is correct, but the file is
> > still found via gcc's STANDARD_INCLUDE_DIR ("/usr/include").
> >
> > I believe, fixincl needs to be extended to behave similarly, but with
> > its STANDARD_INCLUDE_DIR being the initial start directory.
>
> > > > I think the correct thing is to fix the #include statement.
> > > > I do not know if the correct fix is
> > > >
> > > > #include "m328sio.h"
> > > > or
> > > > #include <sys/m328sio.h>
> > > >
> > > > The former is precisely correct.
> > > > Either should do it.
> > > > If the latter breaks, then you must have file name conflicts
> > > > that have incompatible contents. Unlikely at best.
> > > >
> > > > It seems to me that there is such a fix for one of the oddball
> > > > "fixinc.*" files, but I may be misremembering.
> > > >
> > >
> > > I'll look into them.
> >
> > I didn't find such a fix; but as we know now, fixincl ought be able to
> > properly parse even such admittedly bogus include files.
>
> First, lets make sure our goals are in sync.
> The goal is to have the compiler find the same text for m328sio.h it
> would have found it had mvme328 not been edited and relocated.
> Since, by all accounts, that file is not findable from "sys/m328sio.h"
> based in the including directory (/usr/include/sys or any other .../sys
> directory) [i.e. the first attempt], therefore it will be searched for
> using the '<...>' quoting semantics [i.e. the include path search].
> Therefore it will find the same file whether mvme328.h gets edited
> and relocated or not. Because of that, it is not necessary to copy
> the file from /usr/include/sys to /tools/gnu/lib/gcc.....
Maybe you're right, but
>
> Secondly, the current version of fast-fix does exactly the same thing
> as the old fixincludes anyway.
the old fixincludes didn't stop with an error message; right now,
I'm unable to bootstrap... :-(
> I think you are asking for a change
> in behavior.
>
> Third, even if it were decided for aesthetic reasons that it would
> be desireable to copy the file over to /tools/..., the file would
> still be found as if it had been quoted with the '<...>' mechanism.
Yup.
>
> I think we need to leave well enough alone, unless Jeff says he
> wants the new behavior. Even then, I need to ask if the #include
> file ought not get edited into a proper form...
As long as fast-fixincludes doesn't stop in this particular situation...
>
> Regards,
> Bruce
>
manfred