Re: [PATCH] meson: disable PCRE2 dependency by default

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 14, 2025, 15:20 UTC
Message-ID: <xmqqikjuvlxc.fsf@gitster.g>
In-Reply-To: <CAPUEsphoFaS7CnxXs_PsMCtCrB7ByE+y+SxQGaxoovjAdH7UFQ@mail.gmail.com>

Carlo Arenas <carenas@gmail.com> writes:

Show 10 quoted lines

>> For most
>> builds on Linux, the system libpcre2 is the right one and users will
>> expect to find PCRE support by default.
>
> Agree with you on that, and indeed I think every packager
> of git (except for NonStop) does enable it at packaging time.
>
> Maybe this is an argument to enable it by default?, one thing
> that I wonder though, is if we should first isolate the code on
> its own and link it only with `git grep`.

If we decide that PCRE is good enough to do BRE and ERE emulation in compatible enough way more performantly everywhere, it certainly is an option that wrap our calls to platform native regcomp/regexec that we use for our use of BRE/ERE and internally use PCRE for them.

Before that happens, "struct grep_pat" that encapsulates the distinction between using BRE/ERE and PCRE and compile_regexp() that compiles an end-user supplied regular expression string into members of "struct grep_pat" so that it can be used to match against in-core buffer we have, would need to be exposed outside the "grep.[ch]" machinery, and direct uses of regcomp() and regexec() in the rest of the codebase has to be rewritten to work with "struct grep_pat".

And after that happens, teaching "git log --grep=<foo>" and "git blame -L'/<foo>/,/<bar>/'" an equivalent to "git grep -P" option that tells the command that the pattern given is PCRE would come almost for free.

Is that the kind of isolation you are referring to?