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

From: Carlo Arenas <carenas@gmail.com>
Date: Jul 14, 2025, 14:00 UTC
Message-ID: <CAPUEsphoFaS7CnxXs_PsMCtCrB7ByE+y+SxQGaxoovjAdH7UFQ@mail.gmail.com>
In-Reply-To: <aHKgu3Ew3Pk0PL2v@fruit.crustytoothpaste.net>

On Sat, Jul 12, 2025 at 10:51 AM brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 21 quoted lines

>
> On 2025-07-12 at 17:26:15, Carlo Marcelo Arenas Belón wrote:
> > Makefile requires the user to provide the USE_LIBPCRE2 flag to
> > enable this dependency, but meson has it enabled by default,
> > which can be problematic, at least in macOS.
> >
> > While a popular option and matching what was done by cmake
> > (which itself reflects what is preferred by Git for Windows)
> > could result in a broken build or linking with the wrong PCRE2
> > library.
> >
> > While not git's fault, macOS provides a PCRE2 library in base
> > that is not usable (even if it would pass the test) and not
> > configured properly, as it installs a pkgconf module that
> > points to a non existent pcre2.h header in /usr/local/include.
> >
> > Change the default to off, and let the user enable it once a
> > proper dependency is installed or meson instructed to fallback to
> > the wrap.
>
> Can we disable it by default on macOS instead of everywhere?

Yes, but I don't like it much, as it is:

* inconsistent with artifacts created with other build systems
* really an issue that should be fixed by Apple or at least handled
better in meson itself.

> 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`.

I think the rationale behind the current setup was that we will eventually replace all other regex engines with PCRE2, having better performance and retiring compat/regex, but code to do that failed to materialise, and I am not sure how realistic that was.

Carlo

> --
> brian m. carlson (they/them)
> Toronto, Ontario, CA