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

[Bruce Korb <korb at datadesign dot com>]

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

Secondly, the current version of fast-fix does exactly the same thing
as the old fixincludes anyway.  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.

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

Regards,
	Bruce