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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: May 15, 2017, 12:14 UTC
Message-ID: <alpine.DEB.2.21.1.1705151358590.146734@virtualbox>
In-Reply-To: <201705141914.v4EJETGf029570@freefriends.org>

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