Re: Maintainer tools

["Dave Korn" <davek-ml at ntlworld dot com>]

----- Original Message -----
From: "Bruce Korb" <bkorb@allegronetworks.com>
Sent: Monday, April 23, 2001 8:46 PM

> > >I think every person who ever hacked on inclhack.def contacted
> > >me first.
> >
> >   I've hacked on inclhack.def, and although I didn't contact
> > you first, I will now contact you afterward....
>
> You haven't update the repository, therefore it's "first".
> But, ok, *almost* everyone, then.... ;-)

  :-O  Oh, I didn't get your full meaning there.

> > to be anything wrong with it but you might know of some syntax or
> > portability issue I should take care of.
>
> Strictly speaking, no.  There does not seem to be anything wrong.
> I presume you tested them.  However, I do try to strongly emphasize
> in the README that you should consider the `format' fixes before
> `sed' fixes.  Try this :-)  And, please, alphabatize (makes finding
> things easier).

  Errm... the file gcc/fixincs/README in the gcc-2_95-branch just talks
about how the new fast fixincludes system implements the same functionality
as the old shell scripts.  Are you referring to the 3.x version of this
file, or some other readme?  I couldn't find anything that seemed to refer
to 'format' fixes at
http://autogen.freeservers.com/fixincludes/how.html
either.

> `sed' fixes.  Try this :-)  And, please, alphabatize (makes finding
> things easier).

  D'oh, I should have thought of that one myself.  I am tempted to juggle
the hacknames to make sure they stay sequential in the file though, since
the second only makes sense in light of the first and would be, although not
incorrect, superfluous but for the varargs problem.

> + fix = {
> +     hackname = vxworks_varargs_a;
> +     files    = arch/ppc/toolPpc.h;
> +     select   = '/\* GNU C varargs support for the PowerPC with V.4
calling
> sequence';
> +     c_fix    = format;
> +     c_fix_arg = "#ifdef __VXVARGS__\n#include <va_ppc.h>\n#else\n%0";
> +  };

  Ah, I think I see how these work.  Thing is, I'm still on the 2.95 branch;
it seems you've still got your 3.x head on!  There aren't currently any
c_fix hacks in the branch and nor is there a copy of fixfixes.c, so I assume
that adding them now would require a newer autogen to be used on the branch
than is currently the case.  I have no objection to doing it this way; I
assume these compiled fixes must be a good deal faster than invoking sed,
but it seems like a bit much effort and risk for only two fixes!

> + fix = {
> +     hackname = vxworks_varargs_b;
> +     files    = arch/ppc/toolPpc.h;
> +     select   = '/\* END CYGNUS LOCAL Waiting for 2.7.1 to unfreeze \*/';
> +     c_fix    = format;
> +     c_fix_arg = "%0\n#endif /* !defined(__VXVARGS__) */";
> +  };

  I am assuming you had to split the two parts of the fix up simply because
the c_fix / format thing only matches one pattern and one output template at
a time?  Or is there some reason why I shouldn't have had the two sed fixes
in one hack in the original version?  I also notice you changed the select
string to check for the comment markers around it that are evident only from
the sed scripts in my original version; is this just to tighten up on the
slight possibility of a false positive, or is there something subtle here
that I've missed?

> + fix = {
> +     hackname = vxworks_arch_includepath;
> +     files    = arch/ppc/archPpc.h;
> +     select = '(#include.*)"toolPpc.h"';
> +     c_fix    = format;
> +     c_fix_arg = "%1<arch/ppc/toolPpc.h>";
> + };

  And you added brackets here.  Is that a shell metacharacter sort of thing,
or is it just to make a group for the %1, or both?  (I can't remember for
sure, but I think I might have tried selecting on #include and found it
didn't work right in cygwin bash).  If going to new autogen is not an option
(it's Bernd's decision, but I suspect that will be the case), and I have to
keep the sed fixes, should I still make the changes you've made to the
select strings?

  Thanks for taking the time to explain!

      DaveK