gettext: revision, de-keg_only. #53489
Closed
Conversation
This file contains 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
4 tasks
|
Woah thanks for the warning, this would apply to all brew installations on any version of macOS when they run brew update then upgrade next right? Also does this silence the caveat because I remember trying to build zapping from source and it had some voodoo shenanigans in a bootstrap script that failed and the notes helped at least a little. |
Yes.
Yes. |
The changes mean that following those notes should no longer be necessary. |
dscho
added a commit
to dscho/git
that referenced
this pull request
Apr 25, 2020
Apparently a recent Homebrew update now installs `gettext` into a subdirectory under /usr/local/, requiring the CFLAGS/LDFLAGS to list explicit directories _even_ when asking to force-link the `gettext` package. Likewise, the `msgfmt` tool is no longer in the `PATH`. While it is unclear which change is responsible for this breakage (that most notably only occurs on CI build agents that updated very recently), Homebrew/homebrew-core#53489 should fix it. Nevertheless, let's work around this issue, as there are still quite a few build agents out there that need some help in this regard: we explicitly do not call `brew update` in our CI/PR builds anymore. Helped-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
gitster
pushed a commit
to git/git
that referenced
this pull request
Apr 28, 2020
Apparently a recent Homebrew update now installs `gettext` into the subdirectory /usr/local/opt/gettext/[lib/include]. Sometimes the ci job succeeds: brew link --force gettext Linking /usr/local/Cellar/gettext/0.20.1... 179 symlinks created And sometimes installing the package "gettext" with force-link fails: brew link --force gettext Warning: Refusing to link macOS provided/shadowed software: gettext If you need to have gettext first in your PATH run: echo 'export PATH="/usr/local/opt/gettext/bin:$PATH"' >> ~/.bash_profile (And the is not the final word either, since macOS itself says: The default interactive shell is now zsh.) Anyway, The latter requires CFLAGS to include /usr/local/opt/gettext/include and LDFLAGS to include /usr/local/opt/gettext/lib. Likewise, the `msgfmt` tool is no longer in the `PATH`. While it is unclear which change is responsible for this breakage (that most notably only occurs on CI build agents that updated very recently), Homebrew/homebrew-core#53489 has fixed it. Nevertheless, let's work around this issue, as there are still quite a few build agents out there that need some help in this regard: we explicitly do not call `brew update` in our CI/PR builds anymore. Helped-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
dscho
added a commit
to dscho/git
that referenced
this pull request
Apr 30, 2020
Apparently a recent Homebrew update now installs `gettext` into the subdirectory /usr/local/opt/gettext/[lib/include]. Sometimes the ci job succeeds: brew link --force gettext Linking /usr/local/Cellar/gettext/0.20.1... 179 symlinks created And sometimes installing the package "gettext" with force-link fails: brew link --force gettext Warning: Refusing to link macOS provided/shadowed software: gettext If you need to have gettext first in your PATH run: echo 'export PATH="/usr/local/opt/gettext/bin:$PATH"' >> ~/.bash_profile (And the is not the final word either, since macOS itself says: The default interactive shell is now zsh.) Anyway, The latter requires CFLAGS to include /usr/local/opt/gettext/include and LDFLAGS to include /usr/local/opt/gettext/lib. Likewise, the `msgfmt` tool is no longer in the `PATH`. While it is unclear which change is responsible for this breakage (that most notably only occurs on CI build agents that updated very recently), Homebrew/homebrew-core#53489 has fixed it. Nevertheless, let's work around this issue, as there are still quite a few build agents out there that need some help in this regard: we explicitly do not call `brew update` in our CI/PR builds anymore. Helped-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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.
Let's try this and see how many
revisions are required by dependents.Fixes #53485
brew install --build-from-source <formula>, where<formula>is the name of the formula you're submitting?brew test <formula>, where<formula>is the name of the formula you're submitting?brew audit --strict <formula>(after doingbrew install <formula>)?