Re: [PATCH 1/7] compat/regex: add a README with a maintenance guide

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 2441 bytes --]

Hi Arnold,

On Sun, 14 May 2017, arnold@skeeve.com wrote:

> With respect to bug fixes that may have happened downstream, please do
> let me know of any.  But I do request it as a bug report to
> bug-gawk@gnu.org and not just a pull request with no commentary.

I dabbled with updating our compat/regex/ myself, a while ago, and just
found my notes. Note: at least some of these notes should help with the
next iteration of Ævar's patch series.

First of all, our original import could have been accompanied by better
documentation what was done. Granted, back then gawk was still maintained
in CVS, so things would have been a little tougher with regard to, say,
specifying which gawk revision was imported. In the meantime, gawk uses a
Git repository, though: http://git.savannah.gnu.org/r/gawk.git. Therefore,
we can say pretty precisely that gawk's 40b3741f (Bring in development
gawk changes., 2010-11-12)) was imported into Git as per d18f76dccf
(compat/regex: use the regex engine from gawk for compat, 2010-08-17).

My approach of updating compat/regex/ differed from Ævar's in that I
checked out that Git commit, applied the interdiff to gawk's newest
commit, and rebased that onto the current commit of Git. But I think Ævar
& Junio's approach (replace compat/regex/ wholesale by the newest gawk
revision's files, then re-apply clean patches of our `git log 40b3741f..
-- compat/regex/` on top, as individual commits) is saner, as it will make
future updates substantially easier.

With my approach, I still had 16 merge conflicts, pointing in large part
to changes we do *not* want to contribute back: gawk's code style differs
from ours, and we adjusted the files in compat/regex/ to ours (which I
think was a mistake).

I also reinstated support for compiling with NO_MBSUPPORT, which included
a new guard of the btowc() definition.

I also had to reintroduce explicit #defines of bool, true and false, as
gawk's source code split those out into their own header file.

I apparently also "skipped a guarded #include <stddef.h> that was not
actually necessary, but simply a late fixup to a997bf423d (compat/regex:
get the gawk regex engine to compile within git, 2010-08-17)", but I do
not remember what that was about.

In summary, I do not think that any of our patches should go "upstream"
into gawk's source code, as they are pretty specific to Git's needs.

Ciao,
Johannes