From: "Carlo Marcelo Arenas Belón" <carenas@gmail•com>
To: Junio C Hamano <gitster@pobox•com>
Cc: "brian m. carlson" <sandals@crustytoothpaste•net>, git@vger•kernel.org
Subject: Re: [PATCH] meson: disable PCRE2 dependency by default
Date: Mon, 14 Jul 2025 09:46:29 -0700 [thread overview]
Message-ID: <ymreouejava2acp3xpvrviffd3bd7cu3wwmi3fadzykkaaubim@25oyqvcfhrda> (raw)
In-Reply-To: <xmqqikjuvlxc.fsf@gitster.g>
On Mon, Jul 14, 2025 at 08:20:31AM -0800, Junio C Hamano wrote:
> Carlo Arenas <carenas@gmail•com> 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
next prev parent reply other threads:[~2025-07-14 16:46 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-12 17:26 [PATCH] meson: disable PCRE2 dependency by default Carlo Marcelo Arenas Belón
2025-07-12 17:51 ` brian m. carlson
2025-07-14 14:00 ` Carlo Arenas
2025-07-14 15:20 ` Junio C Hamano
2025-07-14 16:46 ` Carlo Marcelo Arenas Belón [this message]
2025-07-14 16:58 ` Junio C Hamano
2025-07-13 12:23 ` [PATCH v2] meson: disable PCRE2 dependency by default in macOS Carlo Marcelo Arenas Belón
2025-07-13 15:42 ` Junio C Hamano
2025-07-13 17:48 ` [PATCH v3] " Carlo Marcelo Arenas Belón
2025-07-15 1:55 ` Eli Schwartz
2025-07-15 8:46 ` Patrick Steinhardt
2025-07-15 8:56 ` Carlo Arenas
2025-07-15 10:32 ` Patrick Steinhardt
2025-07-15 12:08 ` Carlo Arenas
2025-07-15 14:14 ` Eli Schwartz
2025-07-15 12:01 ` Carlo Arenas
2025-07-15 14:22 ` Eli Schwartz
2025-07-15 11:44 ` [PATCH v4] meson: woraround broken system PCRE2 dependency " Carlo Marcelo Arenas Belón
2025-07-15 16:48 ` Junio C Hamano
2025-07-15 16:50 ` Eric Sunshine
2025-07-16 19:30 ` [PATCH v5] meson: work around " Carlo Marcelo Arenas Belón
2025-07-16 21:13 ` Junio C Hamano
2025-07-16 21:17 ` Junio C Hamano
2025-07-16 22:10 ` Eli Schwartz
2025-07-16 22:17 ` Carlo Arenas
2025-07-18 17:02 ` [PATCH v6] " Carlo Marcelo Arenas Belón
2025-07-23 22:17 ` Junio C Hamano
2025-07-24 5:28 ` Patrick Steinhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ymreouejava2acp3xpvrviffd3bd7cu3wwmi3fadzykkaaubim@25oyqvcfhrda \
--to=carenas@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=sandals@crustytoothpaste$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox