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

From: Carlo Marcelo Arenas Belón <[email-masked]>
Date: Mon, 14 Jul 2025 09:46:29 -0700

On Mon, Jul 14, 2025 at 08:20:31AM -0800, Junio C Hamano wrote:
> Carlo Arenas <[email-masked]> writes:
> 
> >> 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?

Thah describes perfectly the probably unrealistic plan I mentioned
in the other part of my response that is not quoted above.

This part was more of a: let's assume that we enable PCRE2 by default
in the Makefile as well, what is the impact to the libification
efforts now that there is a chance that libgit will be linked (probably
statically if using meson) with libpcre2?

Sinvce the plan you mentioned above is still dreamware, wouldn't it be
better to move all the pcre2 functions out of grep.c, export them back
to it through a semi private header and convert `git-grep` into a
standalone binary that might link with pcre2 as needed?

Carlo