Maintainer tools

Maintainer tools

[Bruce Korb]

Geoff wrote:
> So, it is not just "maintainers", it is all users
> who must be able to rebuild the program from source.

In the context of fixincludes, we are talking about
all those developers who are changing the fix definitions,
work on Windows boxes and are unable or unwilling to
rebuild fixincl.x on a separate platform.  I do not
believe this to be a large class of people.

So, anyway, we got lotsa choices:

1.  Continue as we are (AutoGen 4.x for fixincludes &
    the current 5.x for everything else).  This seems
    not to be a big deal.  fixincludes does not exactly
    stretch AutoGen, so I don't need to diddle with it
    very much.

2.  Get a cut-down Guile working on Win-NT (under CygWin?)
    so I can port AG-5.x

3.  Require the above class of developers have access to
    a Guile-enabled box.

4.  Disable include fix hacking on Windows.  (Don't we already
    disable include fixing?)

I think every person who ever hacked on inclhack.def contacted
me first.  I think it safe to say that if the developer class
is non-empty, then it is certainly a group that can be counted
on one hand.  I always figured #1 was easiest, which is why
I never brought it up before.

So, I vote for #1.  I prefer #2, but someone has to get
Guile reliably working on Windows.  #3 and/or #4 are ok by
me, too, but I won't make such a decision.

Regards,
	Bruce

Re: Maintainer tools

[Richard Stallman]

    1.  Continue as we are (AutoGen 4.x for fixincludes &
	the current 5.x for everything else).  This seems
	not to be a big deal.  fixincludes does not exactly
	stretch AutoGen, so I don't need to diddle with it
	very much.

To depend on an old version of a program is a bad state of affairs.
We should avoid it if that is feasible.  #1 is the worst choice.

    2.  Get a cut-down Guile working on Win-NT (under CygWin?)
	so I can port AG-5.x

This is fine, if someone wants to do the work.

    3.  Require the above class of developers have access to
	a Guile-enabled box.

This is acceptable, and takes no work at all.

    4.  Disable include fix hacking on Windows.  (Don't we already
	disable include fixing?)

What is the situation?  Is fixincludes used on Windows?

If fixincludes is not used on Windows, the best solution is #4, which
may be a no-op.  Otherwise, I think #3 is best, unless and until
someone does the work for #2.

RE: Maintainer tools

[David Korn]

>-----Original Message-----
>From: Bruce Korb [ mailto:bkorb@allegronetworks.com ]
>Sent: 16 April 2001 21:37

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

  ... to ask if you'll review my patch, or at any rate just cast an 
experienced eye over the inclhack hunk in it.  I don't think there's likely
to be anything wrong with it but you might know of some syntax or
portability issue I should take care of.

http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00015.html

  The first inclhack is supposed to detect a block of code that has a
comment at the start and end of it, and add a #ifdef-#else-#endif wrapper
around the original contents.  The second hack is supposed to replace a
#include line that uses quotes around the filename with an equivalent
that uses angle brackets (because it's a system file).  I wrote both of
these by basically modelling them along the lines of other hacks I found
that did similar jobs to what I wanted.

      DaveK
-- 
Any sufficiently advanced technology is indistinguishable from a rigged
demo.


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

RE: Maintainer tools

[Bruce Korb]

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

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


+ /*
+  *   Fix VxWorks varargs header
+  */
+ 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";
+  };
+ 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__) */";
+  };
+ 
+ /*
+  *   That last fix won't even work unless we make archPpc.h use the
default
+  *  search path when it includes toolPpc.h
+  *
+  */
+ 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>";
+ };

Re: Maintainer tools

[Dave Korn]

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