Re: PCRE v2 compile error, was Re: What's cooking in git.git (May 2017, #01; Mon, 1)

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: May 3, 2017, 09:45 UTC
Message-ID: <alpine.DEB.2.20.1705031139090.3480@virtualbox>
In-Reply-To: <CACBZZX6-qZLEGob6CEwpJ7jtEBG6WLPdHQsO4DsbkNZ8di5mjg@mail.gmail.com>

Hi Ævar,

On Tue, 2 May 2017, Ævar Arnfjörð Bjarmason wrote:

Show 33 quoted lines

> On Tue, May 2, 2017 at 6:05 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > [... complaint about the abrupt change that makes Git for Windows fail
> >  to build because pcre2.h is missing ...]
>
> I think it's worth it to copy/paste the commit message where I made
> this change, since we're having this discussion in this thread:
> 
>     Makefile & configure: make PCRE v2 the default PCRE implementation
> 
>     Change the USE_LIBPCRE=YesPlease & --with-libpcre flags to the
>     Makefile & configure script, respectively, to mean use PCRE v2, not
>     PCRE v1.
> 
>     The legacy library previously available via those options is still
>     available on request via USE_LIBPCRE1=YesPlease or
>     --with-libpcre1. The existing USE_LIBPCRE2=YesPlease & --with-libpcre2
>     still explicitly ask for v2.
> 
>     The v2 PCRE is stable & end-user compatible, all this change does is
>     change the default. Someone building a new git is likely to also have
>     packaged PCRE v2 sometime in the last 2 years since it was released.
>     If not they can choose to use the legacy v2 library by making the
>     trivial s/USE_LIBPCRE/USE_LIBPCRE1/ change, or package up PCRE v2.
> 
>     New releases of PCRE v2 are already faster than PCRE v1, and not only
>     is all significant development is happening on v2, but bugs in
>     reported against v1 have started getting WONTFIX'd asking users to
>     just upgrade to v2.
> 
>     So it makes sense to give our downstream distributors a nudge to
>     switch over to it.

I see where you are coming from.

At this point, I feel that someone should recall into our collective memory what happened when we made a change similar in nature that broke existing build setups: by requiring REG_STARTEND all of a sudden ("you can easily flip the NO_REGEX switch", as if everybody should know about those Makefile flags we have).

I hate to be that someone, but it has to be said: this is a disruptive change, and it would be a lot better to make it an opt-in at first, and when the dust settled about this option and many distributions have opted in already because of the benefits and tested this thoroughly in practice, then we can think about making this an opt-out option, potentially putting some serious thought into trying to make it painless to upgrade for users casually compiling Git (and not, woohoo, being subscribed to the Git mailing list, let alone knowing about all those Makefile knobs).

In short: it would be a mistake to force PCRE v2 support on by default.

Ciao, Dscho