Re: Fixinc and mvme328.h (2nd try)

[Manfred Hollstein <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