Re: Very promising results with libpcre2

From: Jeffrey Walton <noloader@gmail.com>
Date: Apr 1, 2017, 23:33 UTC
Message-ID: <CAH8yC8mxdNFdpo0ZO0+XpnuHGTpp2NCiMCSE71j2Emt8-NRYDg@mail.gmail.com>
In-Reply-To: <xmqqbmsgugt4.fsf@gitster.mtv.corp.google.com>

Show 19 quoted lines

> Just to make sure that we are on the same page.  While I do not see
> the need to link with both variants and allow users to choose
> between them at runtime, I do not know if the whole world is ready
> to drop pcre1 and use pcre2 (the latter of which has only been
> around for a bit over two years).
>
> So we'd probably want to do
>
>  (1) keep USE_LIBPCRE and enable v1 when set;
>  (2) add USE_LIBPCRE2 and enable v2 when set;
>  (3) make sure to error out when both are set.
>
> or something like that.  It is tempting to allow us to say
>
>     make USE_LIBPCRE=2
>
> but the existing builds are likely to be depending on "is it set to
> anything? then use PCRE1" behaviour, so we unfortunately cannot take
> that route.

Yeah, that's the question I kinda had.

> make USE_LIBPCRE=2

I'd prefer a configure option for consistency. Maybe:

    --with-pcre  # Original PCRE
    --with-pcre1  # Alias
    --with-pcre2  # PCRE2

I prefer it because I usually do the following to see the interesting things that's going on:

    ./configure --help

Often, I find a `--with-ssl` or similar. If `--with-ssl` fails, then I go to the README and INSTALL to fine tune it.

By the way, if you are tweaking Configure, then consider adding a --with-perl=X, too. Its consistent, it side steps the hard coded /usr/bin/perl, and it signals to users its tunable.

Jeff