{"thread":{"id":"65310","subject":"[PATCH] regex: not all macOS platforms seem to have REG_ENHANCED","startedAt":"2026-03-19T22:37:56Z","lastAt":"2026-03-20T16:57:31Z","messageCount":14,"participants":["Junio C Hamano","René Scharfe","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"539433","messageId":"xmqq8qbnigxp.fsf@gitster.g","threadId":"65310","inReplyTo":null,"subject":"[PATCH] regex: not all macOS platforms seem to have REG_ENHANCED","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-03-19T22:37:54Z","receivedAt":"2026-03-19T22:37:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Earlier, 54463d32 (use enhanced basic regular expressions on macOS,\n2023-01-08) started to use the REG_ENHANCED option when ERE is not\nin use on macOS.  The build seems to have started failing on\nmacos-14 CI jobs at GitHub, however, as apparently not all the macOS\nplatforms have this flag defined.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n compat/regcomp_enhanced.c | 2 ++\n 1 file changed, 2 insertions(+)\n\ndiff --git a/compat/regcomp_enhanced.c b/compat/regcomp_enhanced.c\nindex 84193ce53b..51e1358170 100644\n--- a/compat/regcomp_enhanced.c\n+++ b/compat/regcomp_enhanced.c\n@@ -3,7 +3,9 @@\n \n int git_regcomp(regex_t *preg, const char *pattern, int cflags)\n {\n+#ifdef REG_ENHANCED\n \tif (!(cflags & REG_EXTENDED))\n \t\tcflags |= REG_ENHANCED;\n+#endif\n \treturn regcomp(preg, pattern, cflags);\n }\n-- \n2.53.0-816-g44373249a2\n\n"},{"id":"539445","messageId":"6cd35848-a234-40dc-bb87-4c2cb7eff52c@web.de","threadId":"65310","inReplyTo":"xmqq8qbnigxp.fsf@gitster.g","subject":"Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2026-03-19T23:11:43Z","receivedAt":"2026-03-19T23:11:45Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"On 3/19/26 11:37 PM, Junio C Hamano wrote:\n> Earlier, 54463d32 (use enhanced basic regular expressions on macOS,\n> 2023-01-08) started to use the REG_ENHANCED option when ERE is not\n> in use on macOS.  The build seems to have started failing on\n> macos-14 CI jobs at GitHub, however, as apparently not all the macOS\n> platforms have this flag defined.\n\nInteresting.  https://en.wikipedia.org/wiki/MacOS_version_history says\nmacOS 14 (Sonoma) was released 2023-09-26, i.e. more than eight months\nafter the patch.  And the oldest regex(3) man page I could find also\nmentions REG_ENHANCED:\n\nhttps://man.freebsd.org/cgi/man.cgi?query=regex&apropos=0&sektion=0&manpath=macOS+10.12.0&format=html\n\nRené\n\n"},{"id":"539461","messageId":"xmqqv7ergud0.fsf@gitster.g","threadId":"65310","inReplyTo":"6cd35848-a234-40dc-bb87-4c2cb7eff52c@web.de","subject":"Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-03-20T01:30:51Z","receivedAt":"2026-03-20T01:30:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"René Scharfe <l.s.r@web.de> writes:\n\n> On 3/19/26 11:37 PM, Junio C Hamano wrote:\n>> Earlier, 54463d32 (use enhanced basic regular expressions on macOS,\n>> 2023-01-08) started to use the REG_ENHANCED option when ERE is not\n>> in use on macOS.  The build seems to have started failing on\n>> macos-14 CI jobs at GitHub, however, as apparently not all the macOS\n>> platforms have this flag defined.\n>\n> Interesting.  https://en.wikipedia.org/wiki/MacOS_version_history says\n> macOS 14 (Sonoma) was released 2023-09-26, i.e. more than eight months\n> after the patch.  And the oldest regex(3) man page I could find also\n> mentions REG_ENHANCED:\n>\n> https://man.freebsd.org/cgi/man.cgi?query=regex&apropos=0&sektion=0&manpath=macOS+10.12.0&format=html\n\nWell, I have no idea where this breakage came from; it suddenly\nstarted in today's pushout, and I do not think we have made any\nchanges on our end to cause it.\n\nE.g.,\nhttps://github.com/git/git/actions/runs/23315793655/job/67814861386#step:4:301\n\nIn any case, in the same CI run, a few other jobs on osx- that uses\nthe same macos-14 image seem to be passing, so I am reasonably sure\nthat the posted patch is a *bad* idea.  Instead of forcing us to\nfigure out why REG_ENHANCED is missing, it would just hide the\nproblem under the rug, possibly breaking a random regex tests that\nhappen to depend on the \"enhanced mode\" working. X-<.\n\n\n\n"},{"id":"539495","messageId":"3b0be017-2e6c-d1c8-0ed8-88ec4fa66e38@gmx.de","threadId":"65310","inReplyTo":"xmqqv7ergud0.fsf@gitster.g","subject":"Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2026-03-20T07:34:27Z","receivedAt":"2026-03-20T07:34:31Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Fri, 20 Mar 2026, Junio C Hamano wrote:\n\n> René Scharfe <l.s.r@web.de> writes:\n> \n> > On 3/19/26 11:37 PM, Junio C Hamano wrote:\n> >> Earlier, 54463d32 (use enhanced basic regular expressions on macOS,\n> >> 2023-01-08) started to use the REG_ENHANCED option when ERE is not\n> >> in use on macOS.  The build seems to have started failing on\n> >> macos-14 CI jobs at GitHub, however, as apparently not all the macOS\n> >> platforms have this flag defined.\n> >\n> > Interesting.  https://en.wikipedia.org/wiki/MacOS_version_history says\n> > macOS 14 (Sonoma) was released 2023-09-26, i.e. more than eight months\n> > after the patch.  And the oldest regex(3) man page I could find also\n> > mentions REG_ENHANCED:\n> >\n> > https://man.freebsd.org/cgi/man.cgi?query=regex&apropos=0&sektion=0&manpath=macOS+10.12.0&format=html\n> \n> Well, I have no idea where this breakage came from; it suddenly\n> started in today's pushout, and I do not think we have made any\n> changes on our end to cause it.\n> \n> E.g.,\n> https://github.com/git/git/actions/runs/23315793655/job/67814861386#step:4:301\n> \n> In any case, in the same CI run, a few other jobs on osx- that uses\n> the same macos-14 image seem to be passing, so I am reasonably sure\n> that the posted patch is a *bad* idea.  Instead of forcing us to\n> figure out why REG_ENHANCED is missing, it would just hide the\n> problem under the rug, possibly breaking a random regex tests that\n> happen to depend on the \"enhanced mode\" working. X-<.\n\nI also hit this in Git for Windows' \"ever-green\" branches:\nhttps://github.com/git-for-windows/git/actions/runs/23325790048/attempts/1\n\nTHe curious thing is that it only hits `osx-clang` and `osx-reftable`, but\nnot `osx-gcc` nor `osx-meson`.\n\nThe breakage coincides with a runner image version bump: if you expand the\n\"Set up job\" step, and within that step also expand the \"Runner Image\"\ngroup, you will see that the succeeding (older) jobs use 20260302.0147.1,\nthe failing (newer) jobs use 20260317.0174.1. The change that strikes me\nas most likely to be the culprit is the Homebrew bump 5.0.15 -> 5.1.0:\n  https://github.com/actions/runner-images/compare/macos-14-arm64/20260302.0147..macos-14-arm64/20260317.0174#diff-5c04a529d3c8adf7a5f23afe544071dad1853e281c9c7b44cd8d626b6c57444dL35-R35\n\nNow, 3 of the 4 `osx-*` jobs use `clang`, only `osx-gcc` uses `gcc`. So my\nmoney is on a clang update in Homebrew disabling support for\n`REG_ENHANCED`. But why is `osx-meson` not affected, it uses `clang`?\nWell, there's special handling for that in `meson.build`:\nhttps://gitlab.com/git-scm/git/-/blob/v2.53.0/meson.build#L1347-1350\n\n  if compiler.get_define('REG_ENHANCED', prefix: '#include <regex.h>') != ''\n    libgit_c_args += '-DUSE_ENHANCED_BASIC_REGULAR_EXPRESSIONS'\n    libgit_sources += 'compat/regcomp_enhanced.c'\n  endif\n\nI'll continue looking along these lines.\n\nCiao,\nJohannes\n"},{"id":"539497","messageId":"f08f7097-fea8-6dc6-ef49-da0bd5ea3c01@gmx.de","threadId":"65310","inReplyTo":"3b0be017-2e6c-d1c8-0ed8-88ec4fa66e38@gmx.de","subject":"Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2026-03-20T07:48:36Z","receivedAt":"2026-03-20T07:48:42Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 20 Mar 2026, Johannes Schindelin wrote:\n\n> On Fri, 20 Mar 2026, Junio C Hamano wrote:\n> \n> > René Scharfe <l.s.r@web.de> writes:\n> > \n> > > On 3/19/26 11:37 PM, Junio C Hamano wrote:\n> > >> Earlier, 54463d32 (use enhanced basic regular expressions on macOS,\n> > >> 2023-01-08) started to use the REG_ENHANCED option when ERE is not\n> > >> in use on macOS.  The build seems to have started failing on\n> > >> macos-14 CI jobs at GitHub, however, as apparently not all the macOS\n> > >> platforms have this flag defined.\n> > >\n> [...] my money is on a clang update in Homebrew disabling support for\n> `REG_ENHANCED`. But why is `osx-meson` not affected, it uses `clang`?\n> Well, there's special handling for that in `meson.build`:\n> https://gitlab.com/git-scm/git/-/blob/v2.53.0/meson.build#L1347-1350\n> \n>   if compiler.get_define('REG_ENHANCED', prefix: '#include <regex.h>') != ''\n>     libgit_c_args += '-DUSE_ENHANCED_BASIC_REGULAR_EXPRESSIONS'\n>     libgit_sources += 'compat/regcomp_enhanced.c'\n>   endif\n\nAnd it looks indeed as if the `osx-meson` job picks up a difference and\nworks around it. Last week, it detected `REG_ENHANCED`:\nhttps://github.com/git-for-windows/git/actions/runs/22920658960/job/66517862315#step:4:168\n\n>  Fetching value of define \"REG_ENHANCED\" : 0400\n\nThis week, it detects the absence:\nhttps://github.com/git-for-windows/git/actions/runs/23325790048/job/67846594275#step:4:173\n\n> Fetching value of define \"REG_ENHANCED\" : (undefined)\n\nSo there you have it. One week, the `regex.h` headers defined\n`REG_ENHANCED`, the next week, they didn't.\n\nCiao,\nJohannes\n"},{"id":"539498","messageId":"6636e7d2-7a1d-0108-2e62-af27a3ae3cf3@gmx.de","threadId":"65310","inReplyTo":"xmqq8qbnigxp.fsf@gitster.g","subject":"Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2026-03-20T07:55:54Z","receivedAt":"2026-03-20T07:56:01Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Fri, 20 Mar 2026, Junio C Hamano wrote:\n\n> Earlier, 54463d32 (use enhanced basic regular expressions on macOS,\n> 2023-01-08) started to use the REG_ENHANCED option when ERE is not\n> in use on macOS.  The build seems to have started failing on\n> macos-14 CI jobs at GitHub, however, as apparently not all the macOS\n> platforms have this flag defined.\n> \n> Signed-off-by: Junio C Hamano <gitster@pobox.com>\n> ---\n>  compat/regcomp_enhanced.c | 2 ++\n>  1 file changed, 2 insertions(+)\n> \n> diff --git a/compat/regcomp_enhanced.c b/compat/regcomp_enhanced.c\n> index 84193ce53b..51e1358170 100644\n> --- a/compat/regcomp_enhanced.c\n> +++ b/compat/regcomp_enhanced.c\n> @@ -3,7 +3,9 @@\n>  \n>  int git_regcomp(regex_t *preg, const char *pattern, int cflags)\n>  {\n> +#ifdef REG_ENHANCED\n>  \tif (!(cflags & REG_EXTENDED))\n>  \t\tcflags |= REG_ENHANCED;\n> +#endif\n\nWhile this lets the build pass, it _does_ change behavior. Where\npreviously, EREs were enforced, now BREs are silently enforced.\n\nSo it might be desirable to instead imitate what `meson.build` does,\nnamely define `USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` on macOS when\ncompiling with `clang`.\n\nBut that should already be the case:\nhttps://gitlab.com/git-scm/git/-/blob/v2.53.0/config.mak.uname#L151\n\n> ifeq ($(uname_S),Darwin)\n> [...]\n> \tUSE_ENHANCED_BASIC_REGULAR_EXPRESSIONS = YesPlease\n\nSo: hmm.\n\nCiao,\nJohannes\n\n>  \treturn regcomp(preg, pattern, cflags);\n>  }\n> -- \n> 2.53.0-816-g44373249a2\n> \n> \n> \n"},{"id":"539499","messageId":"77b6ec9f-46a5-1f38-9733-188e20da55ec@gmx.de","threadId":"65310","inReplyTo":"6636e7d2-7a1d-0108-2e62-af27a3ae3cf3@gmx.de","subject":"Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2026-03-20T08:06:23Z","receivedAt":"2026-03-20T08:06:26Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Me again,\n\nOn Fri, 20 Mar 2026, Johannes Schindelin wrote:\n\n> On Fri, 20 Mar 2026, Junio C Hamano wrote:\n> \n> > Earlier, 54463d32 (use enhanced basic regular expressions on macOS,\n> > 2023-01-08) started to use the REG_ENHANCED option when ERE is not\n> > in use on macOS.  The build seems to have started failing on\n> > macos-14 CI jobs at GitHub, however, as apparently not all the macOS\n> > platforms have this flag defined.\n> > \n> > Signed-off-by: Junio C Hamano <gitster@pobox.com>\n> > ---\n> >  compat/regcomp_enhanced.c | 2 ++\n> >  1 file changed, 2 insertions(+)\n> > \n> > diff --git a/compat/regcomp_enhanced.c b/compat/regcomp_enhanced.c\n> > index 84193ce53b..51e1358170 100644\n> > --- a/compat/regcomp_enhanced.c\n> > +++ b/compat/regcomp_enhanced.c\n> > @@ -3,7 +3,9 @@\n> >  \n> >  int git_regcomp(regex_t *preg, const char *pattern, int cflags)\n> >  {\n> > +#ifdef REG_ENHANCED\n> >  \tif (!(cflags & REG_EXTENDED))\n> >  \t\tcflags |= REG_ENHANCED;\n> > +#endif\n> \n> While this lets the build pass, it _does_ change behavior. Where\n> previously, EREs were enforced, now BREs are silently enforced.\n> \n> So it might be desirable to instead imitate what `meson.build` does,\n> namely define `USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` on macOS when\n> compiling with `clang`.\n> \n> But that should already be the case:\n> https://gitlab.com/git-scm/git/-/blob/v2.53.0/config.mak.uname#L151\n> \n> > ifeq ($(uname_S),Darwin)\n> > [...]\n> > \tUSE_ENHANCED_BASIC_REGULAR_EXPRESSIONS = YesPlease\n> \n> So: hmm.\n\nAh. That flag _is_ the reason for the build error: I misunderstood what it\nis about. It is not telling the build process to compile with\n`compat/regex.c` and using enhanced regexes, it is telling the build\nprocess that whatever regex library is used _does_ support them.\n\nSo I need to pivot and recommend something like this in the `Darwin`\nclause in `config.mak.uname`:\n\n-- snipsnap --\ndiff --git a/config.mak.uname b/config.mak.uname\nindex f9ffefa67a4f..572f8967bc36 100644\n--- a/config.mak.uname\n+++ b/config.mak.uname\n@@ -172,6 +172,10 @@ ifeq ($(uname_S),Darwin)\n \t\tNEEDS_GOOD_LIBICONV = UnfortunatelyYes\n         endif\n \n+\tifeq ($(CC),clang)\n+\t\tNO_REGEX = HomebrewsClangSeemsToBeMissingEnhancedRegexSupportAsOfMarch2026\n+\tendif\n+\n \t# The builtin FSMonitor on MacOS builds upon Simple-IPC.  Both require\n \t# Unix domain sockets and PThreads.\n         ifndef NO_PTHREADS\n"},{"id":"539500","messageId":"d340af9e-334c-4e81-e58a-fc3dea73ebdd@gmx.de","threadId":"65310","inReplyTo":"77b6ec9f-46a5-1f38-9733-188e20da55ec@gmx.de","subject":"Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2026-03-20T08:55:15Z","receivedAt":"2026-03-20T08:55:19Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Me again, sorry,\n\nOn Fri, 20 Mar 2026, Johannes Schindelin wrote:\n\n> On Fri, 20 Mar 2026, Johannes Schindelin wrote:\n> \n> > On Fri, 20 Mar 2026, Junio C Hamano wrote:\n> > \n> > > The build seems to have started failing on macos-14 CI jobs at\n> > > GitHub, however, as apparently not all the macOS platforms have this\n> > > flag defined.\n> \n> [... I need to ...] recommend something like this in the `Darwin` clause\n> in `config.mak.uname`:\n> \n> -- snipsnap --\n> diff --git a/config.mak.uname b/config.mak.uname\n> index f9ffefa67a4f..572f8967bc36 100644\n> --- a/config.mak.uname\n> +++ b/config.mak.uname\n> @@ -172,6 +172,10 @@ ifeq ($(uname_S),Darwin)\n>  \t\tNEEDS_GOOD_LIBICONV = UnfortunatelyYes\n>          endif\n>  \n> +\tifeq ($(CC),clang)\n> +\t\tNO_REGEX = HomebrewsClangSeemsToBeMissingEnhancedRegexSupportAsOfMarch2026\n> +\tendif\n> +\n>  \t# The builtin FSMonitor on MacOS builds upon Simple-IPC.  Both require\n>  \t# Unix domain sockets and PThreads.\n>          ifndef NO_PTHREADS\n\nTurns out that my analysis was not _quite_ complete yet. With Claude Opus'\nassistance, I was able to find the exact turn of events that led to the CI\nfailure. Here is my proposal for an alternative to your patch, Junio (the\nhttps://github.com/git-for-windows/git/actions/runs/23335584918 shows that\nthe build completed successfully this time; the tests are still running as\nof time of writing, of course):\n\n-- snipsnap --\nFrom f65b3b657c36e9132624ea223c90047527edea59 Mon Sep 17 00:00:00 2001\nFrom: Johannes Schindelin <johannes.schindelin@gmx.de>\nDate: Fri, 20 Mar 2026 09:09:10 +0100\nSubject: [PATCH] osx-clang: work around Homebrew's clang lacking REG_ENHANCED\n\nThe `osx-clang` and `osx-reftable` CI jobs on macOS started failing\nwith:\n\n    compat/regcomp_enhanced.c:7:13: error: use of undeclared identifier\n    'REG_ENHANCED'\n\nThe failure coincides with the GitHub Actions `macos-14-arm64` runner\nimage being updated from `20260302.0147` to `20260317.0174`.  The key\nchange in that image update is the Homebrew version bump from 5.0.15 to\n5.1.0.\n\nHomebrew 5.1.0 introduced automatic linking for versioned keg-only\nformulae when the unversioned sibling is absent (see\nhttps://github.com/Homebrew/brew/pull/21676, announced at\nhttps://brew.sh/2026/03/10/homebrew-5.1.0/).  The runner image installs\n`llvm@15` (keg-only) but not unversioned `llvm`.  Under Homebrew 5.0.x\nthat formula stayed in its keg and its `clang` binary only lived at\n`$(brew --prefix llvm@15)/bin/clang`.  Under 5.1.0, because unversioned\n`llvm` is absent, `llvm@15` is now auto-linked into\n`/opt/homebrew/bin/`, which sits earlier in PATH than `/usr/bin`.\n\nThe net effect is that `CC=clang` in CI now silently resolves to\nHomebrew's LLVM 15.0.7 clang instead of Apple's system clang (Apple\nclang 15.0.0, bundled with Xcode 15.4).  The runner image README\nconfirms this: the reported \"Clang/LLVM\" version flipped from 15.0.0 to\n15.0.7 between image releases, matching the Homebrew LLVM version\nexactly.\n\nHomebrew's LLVM clang uses different include paths from Apple's clang.\nIn particular, the `regex.h` it sees does not define `REG_ENHANCED`,\nwhich is an Apple-specific extension present in the macOS SDK headers\nsince at least macOS 10.12.  The Makefile unconditionally sets\n`USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` for all Darwin builds via\n`config.mak.uname`, which pulls in `compat/regcomp_enhanced.c`, which\nreferences `REG_ENHANCED`, hence the build failure.\n\nThe `osx-gcc` job (CC=gcc-13) is unaffected because Homebrew GCC is\nconfigured to use Apple's SDK sysroot, so it still picks up Apple's\n`regex.h` which defines `REG_ENHANCED`.  The `osx-meson` job is\nunaffected because Meson does a compile-time test for `REG_ENHANCED`\n(via `compiler.get_define`) and simply skips the feature when it is\nabsent.\n\nWork around this by setting `NO_REGEX` when `CC=clang` on Darwin, which\nmakes the build use Git's bundled regex implementation instead of the\nsystem one.  This sidesteps the missing `REG_ENHANCED` define entirely.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n config.mak.uname | 11 +++++++++++\n 1 file changed, 11 insertions(+)\n\ndiff --git a/config.mak.uname b/config.mak.uname\nindex e6efd0f30913..c437accbcc50 100644\n--- a/config.mak.uname\n+++ b/config.mak.uname\n@@ -162,6 +162,17 @@ ifeq ($(uname_S),Darwin)\n \t\tNEEDS_GOOD_LIBICONV = UnfortunatelyYes\n         endif\n \n+\t# Homebrew's LLVM clang ships a regex.h that lacks REG_ENHANCED,\n+\t# which is needed for USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS above.\n+\t# Use our bundled regex instead.  This became a practical problem\n+\t# when Homebrew 5.1.0 started auto-linking versioned keg-only\n+\t# formulae (like llvm@15) into $(HOMEBREW_PREFIX)/bin/, causing\n+\t# CC=clang in CI to silently pick up Homebrew's clang instead of\n+\t# Apple's /usr/bin/clang.\n+\tifeq ($(CC),clang)\n+\t\tNO_REGEX = HomebrewsClangUsesARegexThatLacksREG_ENHANCED\n+\tendif\n+\n \t# The builtin FSMonitor on MacOS builds upon Simple-IPC.  Both require\n \t# Unix domain sockets and PThreads.\n         ifndef NO_PTHREADS\n-- \n2.52.0.windows.1.12.g00d4f5e7d9c\n\n"},{"id":"539511","messageId":"5b8e24c2-452c-486e-a143-386e06a75e03@web.de","threadId":"65310","inReplyTo":"d340af9e-334c-4e81-e58a-fc3dea73ebdd@gmx.de","subject":"Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2026-03-20T11:12:00Z","receivedAt":"2026-03-20T11:12:04Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"On 3/20/26 9:55 AM, Johannes Schindelin wrote:\n> Me again, sorry,\n> \n> On Fri, 20 Mar 2026, Johannes Schindelin wrote:\n> \n>> On Fri, 20 Mar 2026, Johannes Schindelin wrote:\n>>\n>>> On Fri, 20 Mar 2026, Junio C Hamano wrote:\n>>>\n>>>> The build seems to have started failing on macos-14 CI jobs at\n>>>> GitHub, however, as apparently not all the macOS platforms have this\n>>>> flag defined.\n>>\n>> [... I need to ...] recommend something like this in the `Darwin` clause\n>> in `config.mak.uname`:\n>>\n>> -- snipsnap --\n>> diff --git a/config.mak.uname b/config.mak.uname\n>> index f9ffefa67a4f..572f8967bc36 100644\n>> --- a/config.mak.uname\n>> +++ b/config.mak.uname\n>> @@ -172,6 +172,10 @@ ifeq ($(uname_S),Darwin)\n>>  \t\tNEEDS_GOOD_LIBICONV = UnfortunatelyYes\n>>          endif\n>>  \n>> +\tifeq ($(CC),clang)\n>> +\t\tNO_REGEX = HomebrewsClangSeemsToBeMissingEnhancedRegexSupportAsOfMarch2026\n>> +\tendif\n>> +\n>>  \t# The builtin FSMonitor on MacOS builds upon Simple-IPC.  Both require\n>>  \t# Unix domain sockets and PThreads.\n>>          ifndef NO_PTHREADS\n> \n> Turns out that my analysis was not _quite_ complete yet. With Claude Opus'\n> assistance, I was able to find the exact turn of events that led to the CI\n> failure. Here is my proposal for an alternative to your patch, Junio (the\n> https://github.com/git-for-windows/git/actions/runs/23335584918 shows that\n> the build completed successfully this time; the tests are still running as\n> of time of writing, of course):\n> \n> -- snipsnap --\n> From f65b3b657c36e9132624ea223c90047527edea59 Mon Sep 17 00:00:00 2001\n> From: Johannes Schindelin <johannes.schindelin@gmx.de>\n> Date: Fri, 20 Mar 2026 09:09:10 +0100\n> Subject: [PATCH] osx-clang: work around Homebrew's clang lacking REG_ENHANCED\n> \n> The `osx-clang` and `osx-reftable` CI jobs on macOS started failing\n> with:\n> \n>     compat/regcomp_enhanced.c:7:13: error: use of undeclared identifier\n>     'REG_ENHANCED'\n> \n> The failure coincides with the GitHub Actions `macos-14-arm64` runner\n> image being updated from `20260302.0147` to `20260317.0174`.  The key\n> change in that image update is the Homebrew version bump from 5.0.15 to\n> 5.1.0.\n> \n> Homebrew 5.1.0 introduced automatic linking for versioned keg-only\n> formulae when the unversioned sibling is absent (see\n> https://github.com/Homebrew/brew/pull/21676, announced at\n> https://brew.sh/2026/03/10/homebrew-5.1.0/).  The runner image installs\n> `llvm@15` (keg-only) but not unversioned `llvm`.  Under Homebrew 5.0.x\n> that formula stayed in its keg and its `clang` binary only lived at\n> `$(brew --prefix llvm@15)/bin/clang`.  Under 5.1.0, because unversioned\n> `llvm` is absent, `llvm@15` is now auto-linked into\n> `/opt/homebrew/bin/`, which sits earlier in PATH than `/usr/bin`.\n> \n> The net effect is that `CC=clang` in CI now silently resolves to\n> Homebrew's LLVM 15.0.7 clang instead of Apple's system clang (Apple\n> clang 15.0.0, bundled with Xcode 15.4).  The runner image README\n> confirms this: the reported \"Clang/LLVM\" version flipped from 15.0.0 to\n> 15.0.7 between image releases, matching the Homebrew LLVM version\n> exactly.\n\nGood find!\n\n> Homebrew's LLVM clang uses different include paths from Apple's clang.\n> In particular, the `regex.h` it sees does not define `REG_ENHANCED`,\n> which is an Apple-specific extension present in the macOS SDK headers\n> since at least macOS 10.12.  The Makefile unconditionally sets\n> `USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` for all Darwin builds via\n> `config.mak.uname`, which pulls in `compat/regcomp_enhanced.c`, which\n> references `REG_ENHANCED`, hence the build failure.\n\nI suspect it uses the same regex.h.  The definition of REG_ENHANCED is\ngated by a __MAC_OS_X_VERSION_MIN_REQUIRED check, though, and that fails\nbecause __MAC_OS_X_VERSION_MIN_REQUIRED is defined as\n__ENVIRONMENT_OS_VERSION_MIN_REQUIRED__ and that one in turn is not\ndefined by the Homebrew version of clang in the runner.\n\nI can't reproduce this locally, by the way.\n/opt/homebrew/Cellar/llvm/22.1.1/bin/clang is not linked to\n/opt/homebrew/bin on my machine and also provides a sensible definition\nof __MAC_OS_X_VERSION_MIN_REQUIRED.\n\n> The `osx-gcc` job (CC=gcc-13) is unaffected because Homebrew GCC is\n> configured to use Apple's SDK sysroot, so it still picks up Apple's\n> `regex.h` which defines `REG_ENHANCED`.  The `osx-meson` job is\n> unaffected because Meson does a compile-time test for `REG_ENHANCED`\n> (via `compiler.get_define`) and simply skips the feature when it is\n> absent.\n> \n> Work around this by setting `NO_REGEX` when `CC=clang` on Darwin, which\n> makes the build use Git's bundled regex implementation instead of the\n> system one.  This sidesteps the missing `REG_ENHANCED` define entirely.\n\nOr how about using /usr/bin/clang explicitly on macOS instead of any old\nclang from $PATH?  That would avoid user-visible changes.\n\n> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n> ---\n>  config.mak.uname | 11 +++++++++++\n>  1 file changed, 11 insertions(+)\n> \n> diff --git a/config.mak.uname b/config.mak.uname\n> index e6efd0f30913..c437accbcc50 100644\n> --- a/config.mak.uname\n> +++ b/config.mak.uname\n> @@ -162,6 +162,17 @@ ifeq ($(uname_S),Darwin)\n>  \t\tNEEDS_GOOD_LIBICONV = UnfortunatelyYes\n>          endif\n>  \n> +\t# Homebrew's LLVM clang ships a regex.h that lacks REG_ENHANCED,\n> +\t# which is needed for USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS above.\n> +\t# Use our bundled regex instead.  This became a practical problem\n> +\t# when Homebrew 5.1.0 started auto-linking versioned keg-only\n> +\t# formulae (like llvm@15) into $(HOMEBREW_PREFIX)/bin/, causing\n> +\t# CC=clang in CI to silently pick up Homebrew's clang instead of\n> +\t# Apple's /usr/bin/clang.\n> +\tifeq ($(CC),clang)\n> +\t\tNO_REGEX = HomebrewsClangUsesARegexThatLacksREG_ENHANCED\n> +\tendif\n> +\n>  \t# The builtin FSMonitor on MacOS builds upon Simple-IPC.  Both require\n>  \t# Unix domain sockets and PThreads.\n>          ifndef NO_PTHREADS\n\n"},{"id":"539557","messageId":"58f3c772-6d38-0807-29c5-75e26c229c1d@gmx.de","threadId":"65310","inReplyTo":"5b8e24c2-452c-486e-a143-386e06a75e03@web.de","subject":"Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2026-03-20T15:12:20Z","receivedAt":"2026-03-20T15:12:25Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi René,\n\nOn Fri, 20 Mar 2026, René Scharfe wrote:\n\n> On 3/20/26 9:55 AM, Johannes Schindelin wrote:\n> \n> > Homebrew's LLVM clang uses different include paths from Apple's clang.\n> > In particular, the `regex.h` it sees does not define `REG_ENHANCED`,\n> > which is an Apple-specific extension present in the macOS SDK headers\n> > since at least macOS 10.12.  The Makefile unconditionally sets\n> > `USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` for all Darwin builds via\n> > `config.mak.uname`, which pulls in `compat/regcomp_enhanced.c`, which\n> > references `REG_ENHANCED`, hence the build failure.\n> \n> I suspect it uses the same regex.h.  The definition of REG_ENHANCED is\n> gated by a __MAC_OS_X_VERSION_MIN_REQUIRED check, though, and that fails\n> because __MAC_OS_X_VERSION_MIN_REQUIRED is defined as\n> __ENVIRONMENT_OS_VERSION_MIN_REQUIRED__ and that one in turn is not\n> defined by the Homebrew version of clang in the runner.\n\nThat makes sense! I couldn't investigate this because I do not have a\nlocal macOS setup to test with, and I did not want to abuse GitHub\nActions' runners (nor did I want to spend more of my own time on the\ninvestigation).\n\n> I can't reproduce this locally, by the way.\n> /opt/homebrew/Cellar/llvm/22.1.1/bin/clang is not linked to\n> /opt/homebrew/bin on my machine and also provides a sensible definition\n> of __MAC_OS_X_VERSION_MIN_REQUIRED.\n\nHmm. I am convinced, though, that if it hits CI, it hits human users as\nwell. Maybe the difference is that you upgraded from an existing setup\nwhile the runners (I think) are built from scratch every time.\n\n> > The `osx-gcc` job (CC=gcc-13) is unaffected because Homebrew GCC is\n> > configured to use Apple's SDK sysroot, so it still picks up Apple's\n> > `regex.h` which defines `REG_ENHANCED`.  The `osx-meson` job is\n> > unaffected because Meson does a compile-time test for `REG_ENHANCED`\n> > (via `compiler.get_define`) and simply skips the feature when it is\n> > absent.\n> > \n> > Work around this by setting `NO_REGEX` when `CC=clang` on Darwin, which\n> > makes the build use Git's bundled regex implementation instead of the\n> > system one.  This sidesteps the missing `REG_ENHANCED` define entirely.\n> \n> Or how about using /usr/bin/clang explicitly on macOS instead of any old\n> clang from $PATH?  That would avoid user-visible changes.\n\nThat would fix our CI runs, but it would expose users who set their `CC =\nclang` to the same problem that broke our CI builds...\n\nCiao,\nJohannes\n\n> \n> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n> > ---\n> >  config.mak.uname | 11 +++++++++++\n> >  1 file changed, 11 insertions(+)\n> > \n> > diff --git a/config.mak.uname b/config.mak.uname\n> > index e6efd0f30913..c437accbcc50 100644\n> > --- a/config.mak.uname\n> > +++ b/config.mak.uname\n> > @@ -162,6 +162,17 @@ ifeq ($(uname_S),Darwin)\n> >  \t\tNEEDS_GOOD_LIBICONV = UnfortunatelyYes\n> >          endif\n> >  \n> > +\t# Homebrew's LLVM clang ships a regex.h that lacks REG_ENHANCED,\n> > +\t# which is needed for USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS above.\n> > +\t# Use our bundled regex instead.  This became a practical problem\n> > +\t# when Homebrew 5.1.0 started auto-linking versioned keg-only\n> > +\t# formulae (like llvm@15) into $(HOMEBREW_PREFIX)/bin/, causing\n> > +\t# CC=clang in CI to silently pick up Homebrew's clang instead of\n> > +\t# Apple's /usr/bin/clang.\n> > +\tifeq ($(CC),clang)\n> > +\t\tNO_REGEX = HomebrewsClangUsesARegexThatLacksREG_ENHANCED\n> > +\tendif\n> > +\n> >  \t# The builtin FSMonitor on MacOS builds upon Simple-IPC.  Both require\n> >  \t# Unix domain sockets and PThreads.\n> >          ifndef NO_PTHREADS\n> \n> \n> \n"},{"id":"539561","messageId":"2e0df4c6-552c-4293-9d56-46917343ac78@web.de","threadId":"65310","inReplyTo":"58f3c772-6d38-0807-29c5-75e26c229c1d@gmx.de","subject":"Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2026-03-20T15:59:23Z","receivedAt":"2026-03-20T15:59:27Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"On 3/20/26 4:12 PM, Johannes Schindelin wrote:\n> Hi René,\n> \n> On Fri, 20 Mar 2026, René Scharfe wrote:\n> \n>> On 3/20/26 9:55 AM, Johannes Schindelin wrote:\n>>\n>>> Homebrew's LLVM clang uses different include paths from Apple's clang.\n>>> In particular, the `regex.h` it sees does not define `REG_ENHANCED`,\n>>> which is an Apple-specific extension present in the macOS SDK headers\n>>> since at least macOS 10.12.  The Makefile unconditionally sets\n>>> `USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` for all Darwin builds via\n>>> `config.mak.uname`, which pulls in `compat/regcomp_enhanced.c`, which\n>>> references `REG_ENHANCED`, hence the build failure.\n>>\n>> I suspect it uses the same regex.h.  The definition of REG_ENHANCED is\n>> gated by a __MAC_OS_X_VERSION_MIN_REQUIRED check, though, and that fails\n>> because __MAC_OS_X_VERSION_MIN_REQUIRED is defined as\n>> __ENVIRONMENT_OS_VERSION_MIN_REQUIRED__ and that one in turn is not\n>> defined by the Homebrew version of clang in the runner.\n> \n> That makes sense! I couldn't investigate this because I do not have a\n> local macOS setup to test with, and I did not want to abuse GitHub\n> Actions' runners (nor did I want to spend more of my own time on the\n> investigation).\n> \n>> I can't reproduce this locally, by the way.\n>> /opt/homebrew/Cellar/llvm/22.1.1/bin/clang is not linked to\n>> /opt/homebrew/bin on my machine and also provides a sensible definition\n>> of __MAC_OS_X_VERSION_MIN_REQUIRED.\n> \n> Hmm. I am convinced, though, that if it hits CI, it hits human users as\n> well. Maybe the difference is that you upgraded from an existing setup\n> while the runners (I think) are built from scratch every time.\n\nHere's an experiment: This command:\n\n   printf \"%s\\n\" \"#include <regex.h>\" __MAC_OS_X_VERSION_MIN_REQUIRED REG_ENHANCED | clang -E -\n\n... prints the preprocessed regex.h on a macos-14 runner (from the macOS\nSDK, good) as well as the resolved values of the two macros (140000 and\n0400).\n\nCalling make instead of ci/run-build-and-tests.sh lets the build succeed,\nincluding compat/regcomp_enhanced.o.\n\nSo the plain runner is doing fine?\n\n>>> The `osx-gcc` job (CC=gcc-13) is unaffected because Homebrew GCC is\n>>> configured to use Apple's SDK sysroot, so it still picks up Apple's\n>>> `regex.h` which defines `REG_ENHANCED`.  The `osx-meson` job is\n>>> unaffected because Meson does a compile-time test for `REG_ENHANCED`\n>>> (via `compiler.get_define`) and simply skips the feature when it is\n>>> absent.\n>>>\n>>> Work around this by setting `NO_REGEX` when `CC=clang` on Darwin, which\n>>> makes the build use Git's bundled regex implementation instead of the\n>>> system one.  This sidesteps the missing `REG_ENHANCED` define entirely.\n>>\n>> Or how about using /usr/bin/clang explicitly on macOS instead of any old\n>> clang from $PATH?  That would avoid user-visible changes.\n> \n> That would fix our CI runs, but it would expose users who set their `CC =\n> clang` to the same problem that broke our CI builds...\nI still don't get it, but below are two fixes; either works (i.e. only\none of the two files needs to be changed).  But why?  $CUSTOM_PATH only\ncontains p4 and p4d.  My observations don't make much sense, I must be\nlooking at it wrong. :-|\n\nRené\n\n\n .github/workflows/main.yml | 6 +++---\n ci/lib.sh                  | 2 +-\n 2 files changed, 4 insertions(+), 4 deletions(-)\n\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex 826f2f5d3a..f8c6e034ee 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -322,16 +322,16 @@ jobs:\n       matrix:\n         vector:\n           - jobname: osx-clang\n-            cc: clang\n+            cc: /usr/bin/clang\n             pool: macos-14\n           - jobname: osx-reftable\n-            cc: clang\n+            cc: /usr/bin/clang\n             pool: macos-14\n           - jobname: osx-gcc\n             cc: gcc-13\n             pool: macos-14\n           - jobname: osx-meson\n-            cc: clang\n+            cc: /usr/bin/clang\n             pool: macos-14\n     env:\n       CC: ${{matrix.vector.cc}}\ndiff --git a/ci/lib.sh b/ci/lib.sh\nindex 42a2b6a318..6310c16b7a 100755\n--- a/ci/lib.sh\n+++ b/ci/lib.sh\n@@ -346,7 +346,7 @@ macos-*)\n esac\n \n CUSTOM_PATH=\"${CUSTOM_PATH:-$HOME/path}\"\n-export PATH=\"$CUSTOM_PATH:$PATH\"\n+export PATH=\"$PATH:$CUSTOM_PATH\"\n \n case \"$jobname\" in\n linux32)\n\n"},{"id":"539565","messageId":"xmqqldfmfokq.fsf@gitster.g","threadId":"65310","inReplyTo":"5b8e24c2-452c-486e-a143-386e06a75e03@web.de","subject":"Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-03-20T16:33:25Z","receivedAt":"2026-03-20T16:33:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"René Scharfe <l.s.r@web.de> writes:\n\n>> The net effect is that `CC=clang` in CI now silently resolves to\n>> Homebrew's LLVM 15.0.7 clang instead of Apple's system clang (Apple\n>> clang 15.0.0, bundled with Xcode 15.4).  The runner image README\n>> confirms this: the reported \"Clang/LLVM\" version flipped from 15.0.0 to\n>> 15.0.7 between image releases, matching the Homebrew LLVM version\n>> exactly.\n>\n> Good find!\n\nIndeed.  So clang got updated pretty recently (CI runs triggered by\nmy pushing out happens at least once a day and yesterday was the\nfirst time I saw this failure), and that is because Homebrew got\nupdated?\n\n>> Homebrew's LLVM clang uses different include paths from Apple's clang.\n>> In particular, the `regex.h` it sees does not define `REG_ENHANCED`,\n>> which is an Apple-specific extension present in the macOS SDK headers\n>> since at least macOS 10.12.  The Makefile unconditionally sets\n>> `USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` for all Darwin builds via\n>> `config.mak.uname`, which pulls in `compat/regcomp_enhanced.c`, which\n>> references `REG_ENHANCED`, hence the build failure.\n>\n> I suspect it uses the same regex.h.  The definition of REG_ENHANCED is\n> gated by a __MAC_OS_X_VERSION_MIN_REQUIRED check, though, and that fails\n> because __MAC_OS_X_VERSION_MIN_REQUIRED is defined as\n> __ENVIRONMENT_OS_VERSION_MIN_REQUIRED__ and that one in turn is not\n> defined by the Homebrew version of clang in the runner.\n\n> Or how about using /usr/bin/clang explicitly on macOS instead of any old\n> clang from $PATH?  That would avoid user-visible changes.\n\nIf it gives us more stability of CI environment (one fewer thing\nthat can suddenly change the toolset), and makes the environment\ncloser to a typical end-user set-up (hopefully most of them would\nuse what is available in /usr/bin from there, instead of downloading\nnewer versions but possibly built with different/castrated set of\nfeatures), that does look like an attractive alternative to me.\n\n\n"},{"id":"539567","messageId":"xmqqcy0yfnsb.fsf@gitster.g","threadId":"65310","inReplyTo":"6636e7d2-7a1d-0108-2e62-af27a3ae3cf3@gmx.de","subject":"Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-03-20T16:50:28Z","receivedAt":"2026-03-20T16:50:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> While this lets the build pass, it _does_ change behavior. Where\n> previously, EREs were enforced, now BREs are silently enforced.\n\nEnhanced is not about ERE/BRE but yes, you're right.  A build that\ndoes not support REG_ENHANCED (due to the lack of definition in the\nheader) would compile but without enhanced features like \\b, so the\n\"patch\" above would not something I want to apply and blamed by\nmacOS users for X-<.\n\n> So it might be desirable to instead imitate what `meson.build` does,\n> namely define `USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` on macOS when\n> compiling with `clang`.\n>\n> But that should already be the case:\n> https://gitlab.com/git-scm/git/-/blob/v2.53.0/config.mak.uname#L151\n>\n>> ifeq ($(uname_S),Darwin)\n>> [...]\n>> \tUSE_ENHANCED_BASIC_REGULAR_EXPRESSIONS = YesPlease\n>\n> So: hmm.\n\nHmm, indeed.\n"},{"id":"539568","messageId":"xmqq8qbmfngn.fsf@gitster.g","threadId":"65310","inReplyTo":"d340af9e-334c-4e81-e58a-fc3dea73ebdd@gmx.de","subject":"Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-03-20T16:57:28Z","receivedAt":"2026-03-20T16:57:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> Work around this by setting `NO_REGEX` when `CC=clang` on Darwin, which\n> makes the build use Git's bundled regex implementation instead of the\n> system one.  This sidesteps the missing `REG_ENHANCED` define entirely.\n\nWhile this may make things built identically between CI environment\nand end-user environment, do we have to worry about what we lose by\nnot using system supplied regex library?\n\nIf the answer is \"no, we do not lose anything, and even if we do,\nthat's miniscule loss that does not matter\", then I like the\napproach.\n\nI wonder if we could do something like this instead?\n\n\tifeq ($(CC),clang)\n\t\tCC := /usr/bin/clang\n\teneidf\n\nas was suggested in one of the downthread messages by René?\n\nThanks.\n"}]}