Re: Very promising results with libpcre2

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 2, 2017, 03:45 UTC
Message-ID: <xmqqd1cvtquy.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAH8yC8mxdNFdpo0ZO0+XpnuHGTpp2NCiMCSE71j2Emt8-NRYDg@mail.gmail.com>

Jeffrey Walton <noloader@gmail.com> writes:

Show 26 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:
> ...

It is way too early to worry about how ./configure support for this will look like to the end user.

Because our Makefile is designed to be usable without configure, the order we do things will be to first decide how we are going to use Makefile variables to configure the feature (i.e. what you saw that I said to Ævar).

Once we know the decision, then we arrange autoconf to spit out the chosen Makefile variables using --with-pcre or whatever input. This step cannot start before we know the decision of the former. The one who writes --with-pcre support in ./configure would not know if USE_LIBPCRE=YesPlease or something else is the desired output until then.