Link versioned keg-only formulae by default#21676
Merged
Merged
Conversation
MikeMcQuaid
force-pushed
the
link_versioned_keg_only
branch
from
cafd79e to
36cd776
Compare
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates Homebrew’s linking behavior to automatically link keg-only @-versioned and -full formulae by default when no conflicting sibling variants are installed, and adjusts unlink/link messaging and caveats output accordingly.
Changes:
- Extend “sibling” detection to include
-fullvariants and unversioned counterparts, and use it to decide auto-linking/unlinking behavior. - Suppress keg-only caveats/output when a keg-only formula is actually linked, and refine
brew link’s--force/keg-only messaging for versioned keg-only formulae. - Add/extend unit and integration tests for the new default-linking and sibling-grouping behavior.
Reviewed changes
Copilot reviewed 13 out of 13 changed files in this pull request and generated 8 comments.
Show a summary per file
| File | Description |
|---|---|
| Library/Homebrew/formula_installer.rb | Makes link_keg default to “auto-link” for versioned keg-only formulae when safe; adds post-link warning when not linked due to siblings. |
| Library/Homebrew/formula.rb | Adds -full sibling helpers and “link overwrite” sibling graph; updates versioned formula name discovery for -full patterns. |
| Library/Homebrew/unlink.rb | Switches sibling-unlinking from “versioned keg-only only” to the broader “link overwrite” sibling set. |
| Library/Homebrew/cmd/link.rb | Allows linking versioned keg-only without --force and suppresses keg-only path messaging for versioned keg-only formulae. |
| Library/Homebrew/caveats.rb | Omits keg-only caveats text when the formula is linked. |
| Library/Homebrew/tap.rb | Groups foo@X-full under foo-full when building prefix→versioned mapping. |
| Library/Homebrew/install.rb | Uses formula.full_name in the “brew link …” instruction. |
| Library/Homebrew/test/formula_installer_spec.rb | Adds coverage for new default-linking rules and warning text. |
| Library/Homebrew/test/formula_spec.rb | Adds coverage for new -full/unversioned sibling helpers and link-overwrite reasoning. |
| Library/Homebrew/test/tap_spec.rb | Tests prefix_to_versioned_formulae_names grouping for -full versions. |
| Library/Homebrew/test/cmd/link_spec.rb | Integration tests ensuring no unexpected keg-only/caveat output when linking versioned or -full formulae. |
| Library/Homebrew/test/caveats_spec.rb | Tests that keg-only caveats are omitted when the formula is linked. |
| Library/Homebrew/test/unlink_spec.rb | New unit test for unlinking behavior using link_overwrite_formulae. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Link `@` versioned or `-full` formulae by default if their unversioned or unfull siblings are not installed.
MikeMcQuaid
force-pushed
the
link_versioned_keg_only
branch
from
36cd776 to
f383ae2
Compare
p-linnane
approved these changes
Mar 6, 2026
Contributor
|
since this has merged, I'm now seeing dependencies installed by a formula are not linked for example |
Member
|
Same issue seen in Homebrew/core: |
6 tasks
Contributor
|
PR to revert this: #21682 |
cho-m
reviewed
Mar 6, 2026
Comment on lines
-116
to
+119
| @link_keg = T.let(!formula.keg_only? || link_keg, T::Boolean) | ||
| @installed_as_dependency = installed_as_dependency | ||
| @installed_on_request = installed_on_request | ||
| link_keg = !formula.keg_only? || auto_link_versioned_keg_only? if link_keg.nil? | ||
| @link_keg = T.let(link_keg, T::Boolean) |
Member
There was a problem hiding this comment.
Dependency install passes in link_keg: false somewhere. Previously this got overridden by !formula.keg_only? but now it is being set to not link.
Maybe:
brew/Library/Homebrew/formula_installer.rb
Line 888 in bfa73b8
brew/Library/Homebrew/formula_installer.rb
Line 856 in bfa73b8
Lines 255 to 256 in bfa73b8
Contributor
|
probably need some tests with non-keg-only dependencies in formula_installer_spec |
dscho
added a commit
to git-for-windows/git
that referenced
this pull request
Mar 20, 2026
The `osx-clang` and `osx-reftable` CI jobs on macOS started failing
with:
compat/regcomp_enhanced.c:7:13: error: use of undeclared identifier
'REG_ENHANCED'
The failure coincides with the GitHub Actions `macos-14-arm64` runner
image being updated from `20260302.0147` to `20260317.0174`. The key
change in that image update is the Homebrew version bump from 5.0.15 to
5.1.0.
Homebrew 5.1.0 introduced automatic linking for versioned keg-only
formulae when the unversioned sibling is absent (see
Homebrew/brew#21676, announced at
https://brew.sh/2026/03/10/homebrew-5.1.0/). The runner image installs
`llvm@15` (keg-only) but not unversioned `llvm`. Under Homebrew 5.0.x
that formula stayed in its keg and its `clang` binary only lived at
`$(brew --prefix llvm@15)/bin/clang`. Under 5.1.0, because unversioned
`llvm` is absent, `llvm@15` is now auto-linked into
`/opt/homebrew/bin/`, which sits earlier in PATH than `/usr/bin`.
The net effect is that `CC=clang` in CI now silently resolves to
Homebrew's LLVM 15.0.7 clang instead of Apple's system clang (Apple
clang 15.0.0, bundled with Xcode 15.4). The runner image README
confirms this: the reported "Clang/LLVM" version flipped from 15.0.0 to
15.0.7 between image releases, matching the Homebrew LLVM version
exactly.
Homebrew's LLVM clang uses different include paths from Apple's clang.
In particular, the `regex.h` it sees does not define `REG_ENHANCED`,
which is an Apple-specific extension present in the macOS SDK headers
since at least macOS 10.12. The Makefile unconditionally sets
`USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` for all Darwin builds via
`config.mak.uname`, which pulls in `compat/regcomp_enhanced.c`, which
references `REG_ENHANCED`, hence the build failure.
The `osx-gcc` job (CC=gcc-13) is unaffected because Homebrew GCC is
configured to use Apple's SDK sysroot, so it still picks up Apple's
`regex.h` which defines `REG_ENHANCED`. The `osx-meson` job is
unaffected because Meson does a compile-time test for `REG_ENHANCED`
(via `compiler.get_define`) and simply skips the feature when it is
absent.
Work around this by setting `NO_REGEX` when `CC=clang` on Darwin, which
makes the build use Git's bundled regex implementation instead of the
system one. This sidesteps the missing `REG_ENHANCED` define entirely.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to git-for-windows/git
that referenced
this pull request
Mar 20, 2026
The `osx-clang` and `osx-reftable` CI jobs on macOS started failing
with:
compat/regcomp_enhanced.c:7:13: error: use of undeclared identifier
'REG_ENHANCED'
The failure coincides with the GitHub Actions `macos-14-arm64` runner
image being updated from `20260302.0147` to `20260317.0174`. The key
change in that image update is the Homebrew version bump from 5.0.15 to
5.1.0.
Homebrew 5.1.0 introduced automatic linking for versioned keg-only
formulae when the unversioned sibling is absent (see
Homebrew/brew#21676, announced at
https://brew.sh/2026/03/10/homebrew-5.1.0/). The runner image installs
`llvm@15` (keg-only) but not unversioned `llvm`. Under Homebrew 5.0.x
that formula stayed in its keg and its `clang` binary only lived at
`$(brew --prefix llvm@15)/bin/clang`. Under 5.1.0, because unversioned
`llvm` is absent, `llvm@15` is now auto-linked into
`/opt/homebrew/bin/`, which sits earlier in PATH than `/usr/bin`.
The net effect is that `CC=clang` in CI now silently resolves to
Homebrew's LLVM 15.0.7 clang instead of Apple's system clang (Apple
clang 15.0.0, bundled with Xcode 15.4). The runner image README
confirms this: the reported "Clang/LLVM" version flipped from 15.0.0 to
15.0.7 between image releases, matching the Homebrew LLVM version
exactly.
Homebrew's LLVM clang uses different include paths from Apple's clang.
In particular, the `regex.h` it sees does not define `REG_ENHANCED`,
which is an Apple-specific extension present in the macOS SDK headers
since at least macOS 10.12. The Makefile unconditionally sets
`USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` for all Darwin builds via
`config.mak.uname`, which pulls in `compat/regcomp_enhanced.c`, which
references `REG_ENHANCED`, hence the build failure.
The `osx-gcc` job (CC=gcc-13) is unaffected because Homebrew GCC is
configured to use Apple's SDK sysroot, so it still picks up Apple's
`regex.h` which defines `REG_ENHANCED`. The `osx-meson` job is
unaffected because Meson does a compile-time test for `REG_ENHANCED`
(via `compiler.get_define`) and simply skips the feature when it is
absent.
Work around this by setting `NO_REGEX` when `CC=clang` on Darwin, which
makes the build use Git's bundled regex implementation instead of the
system one. This sidesteps the missing `REG_ENHANCED` define entirely.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
jollaitbot
pushed a commit
to sailfishos-mirror/git
that referenced
this pull request
Mar 21, 2026
The `osx-clang` and `osx-reftable` CI jobs on macOS started failing
with:
compat/regcomp_enhanced.c:7:13: error: use of undeclared identifier
'REG_ENHANCED'
The failure coincides with the GitHub Actions `macos-14-arm64` runner
image being updated from `20260302.0147` to `20260317.0174`. The key
change in that image update is the Homebrew version bump from 5.0.15 to
5.1.0.
Homebrew 5.1.0 introduced automatic linking for versioned keg-only
formulae when the unversioned sibling is absent (see
Homebrew/brew#21676, announced at
https://brew.sh/2026/03/10/homebrew-5.1.0/). The runner image installs
`llvm@15` (keg-only) but not unversioned `llvm`. Under Homebrew 5.0.x
that formula stayed in its keg and its `clang` binary only lived at
`$(brew --prefix llvm@15)/bin/clang`. Under 5.1.0, because unversioned
`llvm` is absent, `llvm@15` is now auto-linked into
`/opt/homebrew/bin/`, which sits earlier in PATH than `/usr/bin`.
The net effect is that `CC=clang` in CI now silently resolves to
Homebrew's LLVM 15.0.7 clang instead of Apple's system clang (Apple
clang 15.0.0, bundled with Xcode 15.4). The runner image README
confirms this: the reported "Clang/LLVM" version flipped from 15.0.0 to
15.0.7 between image releases, matching the Homebrew LLVM version
exactly.
Homebrew's LLVM clang uses different include paths from Apple's clang.
In particular, the `regex.h` it sees does not define `REG_ENHANCED`,
which is an Apple-specific extension present in the macOS SDK headers
since at least macOS 10.12. The Makefile unconditionally sets
`USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` for all Darwin builds via
`config.mak.uname`, which pulls in `compat/regcomp_enhanced.c`, which
references `REG_ENHANCED`, hence the build failure.
The `osx-gcc` job (CC=gcc-13) is unaffected because Homebrew GCC is
configured to use Apple's SDK sysroot, so it still picks up Apple's
`regex.h` which defines `REG_ENHANCED`. The `osx-meson` job is
unaffected because Meson does a compile-time test for `REG_ENHANCED`
(via `compiler.get_define`) and simply skips the feature when it is
absent.
Work around this by setting `NO_REGEX` when `CC=clang` on Darwin, which
makes the build use Git's bundled regex implementation instead of the
system one. This sidesteps the missing `REG_ENHANCED` define entirely.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitforwindowshelper Bot
pushed a commit
to git-for-windows/shears-builds
that referenced
this pull request
Mar 22, 2026
The `osx-clang` and `osx-reftable` CI jobs on macOS started failing
with:
compat/regcomp_enhanced.c:7:13: error: use of undeclared identifier
'REG_ENHANCED'
The failure coincides with the GitHub Actions `macos-14-arm64` runner
image being updated from `20260302.0147` to `20260317.0174`. The key
change in that image update is the Homebrew version bump from 5.0.15 to
5.1.0.
Homebrew 5.1.0 introduced automatic linking for versioned keg-only
formulae when the unversioned sibling is absent (see
Homebrew/brew#21676, announced at
https://brew.sh/2026/03/10/homebrew-5.1.0/). The runner image installs
`llvm@15` (keg-only) but not unversioned `llvm`. Under Homebrew 5.0.x
that formula stayed in its keg and its `clang` binary only lived at
`$(brew --prefix llvm@15)/bin/clang`. Under 5.1.0, because unversioned
`llvm` is absent, `llvm@15` is now auto-linked into
`/opt/homebrew/bin/`, which sits earlier in PATH than `/usr/bin`.
The net effect is that `CC=clang` in CI now silently resolves to
Homebrew's LLVM 15.0.7 clang instead of Apple's system clang (Apple
clang 15.0.0, bundled with Xcode 15.4). The runner image README
confirms this: the reported "Clang/LLVM" version flipped from 15.0.0 to
15.0.7 between image releases, matching the Homebrew LLVM version
exactly.
Homebrew's LLVM clang uses different include paths from Apple's clang.
In particular, the `regex.h` it sees does not define `REG_ENHANCED`,
which is an Apple-specific extension present in the macOS SDK headers
since at least macOS 10.12. The Makefile unconditionally sets
`USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` for all Darwin builds via
`config.mak.uname`, which pulls in `compat/regcomp_enhanced.c`, which
references `REG_ENHANCED`, hence the build failure.
The `osx-gcc` job (CC=gcc-13) is unaffected because Homebrew GCC is
configured to use Apple's SDK sysroot, so it still picks up Apple's
`regex.h` which defines `REG_ENHANCED`. The `osx-meson` job is
unaffected because Meson does a compile-time test for `REG_ENHANCED`
(via `compiler.get_define`) and simply skips the feature when it is
absent.
Work around this by setting `NO_REGEX` when `CC=clang` on Darwin, which
makes the build use Git's bundled regex implementation instead of the
system one. This sidesteps the missing `REG_ENHANCED` define entirely.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
gitforwindowshelper Bot
pushed a commit
to git-for-windows/shears-builds
that referenced
this pull request
Mar 24, 2026
The `osx-clang` and `osx-reftable` CI jobs on macOS started failing
with:
compat/regcomp_enhanced.c:7:13: error: use of undeclared identifier
'REG_ENHANCED'
The failure coincides with the GitHub Actions `macos-14-arm64` runner
image being updated from `20260302.0147` to `20260317.0174`. The key
change in that image update is the Homebrew version bump from 5.0.15 to
5.1.0.
Homebrew 5.1.0 introduced automatic linking for versioned keg-only
formulae when the unversioned sibling is absent (see
Homebrew/brew#21676, announced at
https://brew.sh/2026/03/10/homebrew-5.1.0/). The runner image installs
`llvm@15` (keg-only) but not unversioned `llvm`. Under Homebrew 5.0.x
that formula stayed in its keg and its `clang` binary only lived at
`$(brew --prefix llvm@15)/bin/clang`. Under 5.1.0, because unversioned
`llvm` is absent, `llvm@15` is now auto-linked into
`/opt/homebrew/bin/`, which sits earlier in PATH than `/usr/bin`.
The net effect is that `CC=clang` in CI now silently resolves to
Homebrew's LLVM 15.0.7 clang instead of Apple's system clang (Apple
clang 15.0.0, bundled with Xcode 15.4). The runner image README
confirms this: the reported "Clang/LLVM" version flipped from 15.0.0 to
15.0.7 between image releases, matching the Homebrew LLVM version
exactly.
Homebrew's LLVM clang uses different include paths from Apple's clang.
In particular, the `regex.h` it sees does not define `REG_ENHANCED`,
which is an Apple-specific extension present in the macOS SDK headers
since at least macOS 10.12. The Makefile unconditionally sets
`USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` for all Darwin builds via
`config.mak.uname`, which pulls in `compat/regcomp_enhanced.c`, which
references `REG_ENHANCED`, hence the build failure.
The `osx-gcc` job (CC=gcc-13) is unaffected because Homebrew GCC is
configured to use Apple's SDK sysroot, so it still picks up Apple's
`regex.h` which defines `REG_ENHANCED`. The `osx-meson` job is
unaffected because Meson does a compile-time test for `REG_ENHANCED`
(via `compiler.get_define`) and simply skips the feature when it is
absent.
Work around this by setting `NO_REGEX` when `CC=clang` on Darwin, which
makes the build use Git's bundled regex implementation instead of the
system one. This sidesteps the missing `REG_ENHANCED` define entirely.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
gitforwindowshelper Bot
pushed a commit
to git-for-windows/git
that referenced
this pull request
Mar 25, 2026
The `osx-clang` and `osx-reftable` CI jobs on macOS started failing
with:
compat/regcomp_enhanced.c:7:13: error: use of undeclared identifier
'REG_ENHANCED'
The failure coincides with the GitHub Actions `macos-14-arm64` runner
image being updated from `20260302.0147` to `20260317.0174`. The key
change in that image update is the Homebrew version bump from 5.0.15 to
5.1.0.
Homebrew 5.1.0 introduced automatic linking for versioned keg-only
formulae when the unversioned sibling is absent (see
Homebrew/brew#21676, announced at
https://brew.sh/2026/03/10/homebrew-5.1.0/). The runner image installs
`llvm@15` (keg-only) but not unversioned `llvm`. Under Homebrew 5.0.x
that formula stayed in its keg and its `clang` binary only lived at
`$(brew --prefix llvm@15)/bin/clang`. Under 5.1.0, because unversioned
`llvm` is absent, `llvm@15` is now auto-linked into
`/opt/homebrew/bin/`, which sits earlier in PATH than `/usr/bin`.
The net effect is that `CC=clang` in CI now silently resolves to
Homebrew's LLVM 15.0.7 clang instead of Apple's system clang (Apple
clang 15.0.0, bundled with Xcode 15.4). The runner image README
confirms this: the reported "Clang/LLVM" version flipped from 15.0.0 to
15.0.7 between image releases, matching the Homebrew LLVM version
exactly.
Homebrew's LLVM clang uses different include paths from Apple's clang.
In particular, the `regex.h` it sees does not define `REG_ENHANCED`,
which is an Apple-specific extension present in the macOS SDK headers
since at least macOS 10.12. The Makefile unconditionally sets
`USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` for all Darwin builds via
`config.mak.uname`, which pulls in `compat/regcomp_enhanced.c`, which
references `REG_ENHANCED`, hence the build failure.
The `osx-gcc` job (CC=gcc-13) is unaffected because Homebrew GCC is
configured to use Apple's SDK sysroot, so it still picks up Apple's
`regex.h` which defines `REG_ENHANCED`. The `osx-meson` job is
unaffected because Meson does a compile-time test for `REG_ENHANCED`
(via `compiler.get_define`) and simply skips the feature when it is
absent.
Work around this by setting `NO_REGEX` when `CC=clang` on Darwin, which
makes the build use Git's bundled regex implementation instead of the
system one. This sidesteps the missing `REG_ENHANCED` define entirely.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
gitforwindowshelper Bot
pushed a commit
to git-for-windows/git
that referenced
this pull request
Mar 26, 2026
The `osx-clang` and `osx-reftable` CI jobs on macOS started failing
with:
compat/regcomp_enhanced.c:7:13: error: use of undeclared identifier
'REG_ENHANCED'
The failure coincides with the GitHub Actions `macos-14-arm64` runner
image being updated from `20260302.0147` to `20260317.0174`. The key
change in that image update is the Homebrew version bump from 5.0.15 to
5.1.0.
Homebrew 5.1.0 introduced automatic linking for versioned keg-only
formulae when the unversioned sibling is absent (see
Homebrew/brew#21676, announced at
https://brew.sh/2026/03/10/homebrew-5.1.0/). The runner image installs
`llvm@15` (keg-only) but not unversioned `llvm`. Under Homebrew 5.0.x
that formula stayed in its keg and its `clang` binary only lived at
`$(brew --prefix llvm@15)/bin/clang`. Under 5.1.0, because unversioned
`llvm` is absent, `llvm@15` is now auto-linked into
`/opt/homebrew/bin/`, which sits earlier in PATH than `/usr/bin`.
The net effect is that `CC=clang` in CI now silently resolves to
Homebrew's LLVM 15.0.7 clang instead of Apple's system clang (Apple
clang 15.0.0, bundled with Xcode 15.4). The runner image README
confirms this: the reported "Clang/LLVM" version flipped from 15.0.0 to
15.0.7 between image releases, matching the Homebrew LLVM version
exactly.
Homebrew's LLVM clang uses different include paths from Apple's clang.
In particular, the `regex.h` it sees does not define `REG_ENHANCED`,
which is an Apple-specific extension present in the macOS SDK headers
since at least macOS 10.12. The Makefile unconditionally sets
`USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` for all Darwin builds via
`config.mak.uname`, which pulls in `compat/regcomp_enhanced.c`, which
references `REG_ENHANCED`, hence the build failure.
The `osx-gcc` job (CC=gcc-13) is unaffected because Homebrew GCC is
configured to use Apple's SDK sysroot, so it still picks up Apple's
`regex.h` which defines `REG_ENHANCED`. The `osx-meson` job is
unaffected because Meson does a compile-time test for `REG_ENHANCED`
(via `compiler.get_define`) and simply skips the feature when it is
absent.
Work around this by setting `NO_REGEX` when `CC=clang` on Darwin, which
makes the build use Git's bundled regex implementation instead of the
system one. This sidesteps the missing `REG_ENHANCED` define entirely.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
gitforwindowshelper Bot
pushed a commit
to git-for-windows/shears-builds
that referenced
this pull request
Mar 28, 2026
The `osx-clang` and `osx-reftable` CI jobs on macOS started failing
with:
compat/regcomp_enhanced.c:7:13: error: use of undeclared identifier
'REG_ENHANCED'
The failure coincides with the GitHub Actions `macos-14-arm64` runner
image being updated from `20260302.0147` to `20260317.0174`. The key
change in that image update is the Homebrew version bump from 5.0.15 to
5.1.0.
Homebrew 5.1.0 introduced automatic linking for versioned keg-only
formulae when the unversioned sibling is absent (see
Homebrew/brew#21676, announced at
https://brew.sh/2026/03/10/homebrew-5.1.0/). The runner image installs
`llvm@15` (keg-only) but not unversioned `llvm`. Under Homebrew 5.0.x
that formula stayed in its keg and its `clang` binary only lived at
`$(brew --prefix llvm@15)/bin/clang`. Under 5.1.0, because unversioned
`llvm` is absent, `llvm@15` is now auto-linked into
`/opt/homebrew/bin/`, which sits earlier in PATH than `/usr/bin`.
The net effect is that `CC=clang` in CI now silently resolves to
Homebrew's LLVM 15.0.7 clang instead of Apple's system clang (Apple
clang 15.0.0, bundled with Xcode 15.4). The runner image README
confirms this: the reported "Clang/LLVM" version flipped from 15.0.0 to
15.0.7 between image releases, matching the Homebrew LLVM version
exactly.
Homebrew's LLVM clang uses different include paths from Apple's clang.
In particular, the `regex.h` it sees does not define `REG_ENHANCED`,
which is an Apple-specific extension present in the macOS SDK headers
since at least macOS 10.12. The Makefile unconditionally sets
`USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` for all Darwin builds via
`config.mak.uname`, which pulls in `compat/regcomp_enhanced.c`, which
references `REG_ENHANCED`, hence the build failure.
The `osx-gcc` job (CC=gcc-13) is unaffected because Homebrew GCC is
configured to use Apple's SDK sysroot, so it still picks up Apple's
`regex.h` which defines `REG_ENHANCED`. The `osx-meson` job is
unaffected because Meson does a compile-time test for `REG_ENHANCED`
(via `compiler.get_define`) and simply skips the feature when it is
absent.
Work around this by setting `NO_REGEX` when `CC=clang` on Darwin, which
makes the build use Git's bundled regex implementation instead of the
system one. This sidesteps the missing `REG_ENHANCED` define entirely.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
gitforwindowshelper Bot
pushed a commit
to git-for-windows/git
that referenced
this pull request
Mar 31, 2026
The `osx-clang` and `osx-reftable` CI jobs on macOS started failing
with:
compat/regcomp_enhanced.c:7:13: error: use of undeclared identifier
'REG_ENHANCED'
The failure coincides with the GitHub Actions `macos-14-arm64` runner
image being updated from `20260302.0147` to `20260317.0174`. The key
change in that image update is the Homebrew version bump from 5.0.15 to
5.1.0.
Homebrew 5.1.0 introduced automatic linking for versioned keg-only
formulae when the unversioned sibling is absent (see
Homebrew/brew#21676, announced at
https://brew.sh/2026/03/10/homebrew-5.1.0/). The runner image installs
`llvm@15` (keg-only) but not unversioned `llvm`. Under Homebrew 5.0.x
that formula stayed in its keg and its `clang` binary only lived at
`$(brew --prefix llvm@15)/bin/clang`. Under 5.1.0, because unversioned
`llvm` is absent, `llvm@15` is now auto-linked into
`/opt/homebrew/bin/`, which sits earlier in PATH than `/usr/bin`.
The net effect is that `CC=clang` in CI now silently resolves to
Homebrew's LLVM 15.0.7 clang instead of Apple's system clang (Apple
clang 15.0.0, bundled with Xcode 15.4). The runner image README
confirms this: the reported "Clang/LLVM" version flipped from 15.0.0 to
15.0.7 between image releases, matching the Homebrew LLVM version
exactly.
Homebrew's LLVM clang uses different include paths from Apple's clang.
In particular, the `regex.h` it sees does not define `REG_ENHANCED`,
which is an Apple-specific extension present in the macOS SDK headers
since at least macOS 10.12. The Makefile unconditionally sets
`USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` for all Darwin builds via
`config.mak.uname`, which pulls in `compat/regcomp_enhanced.c`, which
references `REG_ENHANCED`, hence the build failure.
The `osx-gcc` job (CC=gcc-13) is unaffected because Homebrew GCC is
configured to use Apple's SDK sysroot, so it still picks up Apple's
`regex.h` which defines `REG_ENHANCED`. The `osx-meson` job is
unaffected because Meson does a compile-time test for `REG_ENHANCED`
(via `compiler.get_define`) and simply skips the feature when it is
absent.
Work around this by setting `NO_REGEX` when `CC=clang` on Darwin, which
makes the build use Git's bundled regex implementation instead of the
system one. This sidesteps the missing `REG_ENHANCED` define entirely.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
gitforwindowshelper Bot
pushed a commit
to git-for-windows/shears-builds
that referenced
this pull request
Apr 2, 2026
The `osx-clang` and `osx-reftable` CI jobs on macOS started failing
with:
compat/regcomp_enhanced.c:7:13: error: use of undeclared identifier
'REG_ENHANCED'
The failure coincides with the GitHub Actions `macos-14-arm64` runner
image being updated from `20260302.0147` to `20260317.0174`. The key
change in that image update is the Homebrew version bump from 5.0.15 to
5.1.0.
Homebrew 5.1.0 introduced automatic linking for versioned keg-only
formulae when the unversioned sibling is absent (see
Homebrew/brew#21676, announced at
https://brew.sh/2026/03/10/homebrew-5.1.0/). The runner image installs
`llvm@15` (keg-only) but not unversioned `llvm`. Under Homebrew 5.0.x
that formula stayed in its keg and its `clang` binary only lived at
`$(brew --prefix llvm@15)/bin/clang`. Under 5.1.0, because unversioned
`llvm` is absent, `llvm@15` is now auto-linked into
`/opt/homebrew/bin/`, which sits earlier in PATH than `/usr/bin`.
The net effect is that `CC=clang` in CI now silently resolves to
Homebrew's LLVM 15.0.7 clang instead of Apple's system clang (Apple
clang 15.0.0, bundled with Xcode 15.4). The runner image README
confirms this: the reported "Clang/LLVM" version flipped from 15.0.0 to
15.0.7 between image releases, matching the Homebrew LLVM version
exactly.
Homebrew's LLVM clang uses different include paths from Apple's clang.
In particular, the `regex.h` it sees does not define `REG_ENHANCED`,
which is an Apple-specific extension present in the macOS SDK headers
since at least macOS 10.12. The Makefile unconditionally sets
`USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` for all Darwin builds via
`config.mak.uname`, which pulls in `compat/regcomp_enhanced.c`, which
references `REG_ENHANCED`, hence the build failure.
The `osx-gcc` job (CC=gcc-13) is unaffected because Homebrew GCC is
configured to use Apple's SDK sysroot, so it still picks up Apple's
`regex.h` which defines `REG_ENHANCED`. The `osx-meson` job is
unaffected because Meson does a compile-time test for `REG_ENHANCED`
(via `compiler.get_define`) and simply skips the feature when it is
absent.
Work around this by setting `NO_REGEX` when `CC=clang` on Darwin, which
makes the build use Git's bundled regex implementation instead of the
system one. This sidesteps the missing `REG_ENHANCED` define entirely.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
gitforwindowshelper Bot
pushed a commit
to git-for-windows/git
that referenced
this pull request
Apr 2, 2026
The `osx-clang` and `osx-reftable` CI jobs on macOS started failing
with:
compat/regcomp_enhanced.c:7:13: error: use of undeclared identifier
'REG_ENHANCED'
The failure coincides with the GitHub Actions `macos-14-arm64` runner
image being updated from `20260302.0147` to `20260317.0174`. The key
change in that image update is the Homebrew version bump from 5.0.15 to
5.1.0.
Homebrew 5.1.0 introduced automatic linking for versioned keg-only
formulae when the unversioned sibling is absent (see
Homebrew/brew#21676, announced at
https://brew.sh/2026/03/10/homebrew-5.1.0/). The runner image installs
`llvm@15` (keg-only) but not unversioned `llvm`. Under Homebrew 5.0.x
that formula stayed in its keg and its `clang` binary only lived at
`$(brew --prefix llvm@15)/bin/clang`. Under 5.1.0, because unversioned
`llvm` is absent, `llvm@15` is now auto-linked into
`/opt/homebrew/bin/`, which sits earlier in PATH than `/usr/bin`.
The net effect is that `CC=clang` in CI now silently resolves to
Homebrew's LLVM 15.0.7 clang instead of Apple's system clang (Apple
clang 15.0.0, bundled with Xcode 15.4). The runner image README
confirms this: the reported "Clang/LLVM" version flipped from 15.0.0 to
15.0.7 between image releases, matching the Homebrew LLVM version
exactly.
Homebrew's LLVM clang uses different include paths from Apple's clang.
In particular, the `regex.h` it sees does not define `REG_ENHANCED`,
which is an Apple-specific extension present in the macOS SDK headers
since at least macOS 10.12. The Makefile unconditionally sets
`USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` for all Darwin builds via
`config.mak.uname`, which pulls in `compat/regcomp_enhanced.c`, which
references `REG_ENHANCED`, hence the build failure.
The `osx-gcc` job (CC=gcc-13) is unaffected because Homebrew GCC is
configured to use Apple's SDK sysroot, so it still picks up Apple's
`regex.h` which defines `REG_ENHANCED`. The `osx-meson` job is
unaffected because Meson does a compile-time test for `REG_ENHANCED`
(via `compiler.get_define`) and simply skips the feature when it is
absent.
Work around this by setting `NO_REGEX` when `CC=clang` on Darwin, which
makes the build use Git's bundled regex implementation instead of the
system one. This sidesteps the missing `REG_ENHANCED` define entirely.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Link
@versioned or-fullformulae by default if their unversioned or unfull siblings are not installed.brew lgtm(style, typechecking and tests) with your changes locally?Used OpenAI Codex 5.4 and manually reviewed, hand edited and tested all changes.