On Sat, Apr 25, 2020 at 12:54:26PM +0000, Johannes Schindelin via GitGitGadget wrote:
> diff --git a/config.mak.uname b/config.mak.uname
> index 0ab8e009383..1ea16e89288 100644
> --- a/config.mak.uname
> +++ b/config.mak.uname
> @@ -133,8 +133,17 @@ ifeq ($(uname_S),Darwin)
> HAVE_BSD_SYSCTL = YesPlease
> FREAD_READS_DIRECTORIES = UnfortunatelyYes
> HAVE_NS_GET_EXECUTABLE_PATH = YesPlease
> - BASIC_CFLAGS += -I/usr/local/include
> - BASIC_LDFLAGS += -L/usr/local/lib
keeping these flags independenly allows people that doesn't have brew or that
have brew but hadn't installed the gettext package, to still be able to use
other libraries/packages that could be installed in those directories
either through brew (ex: libgcrypt, openssl or pcre*) or manually while
also using a compiler that doesn't use by default /usr/local/{include,lib}.
even if all this might sound like a stretch, notice that it happened before
as shown by 2a1377a2a (macOS: make sure that gettext is found, 2019-04-14)
> + # Workaround for `gettext` being keg-only and not even being linked via
> + # `brew link --force gettext`, should be obsolete as of
> + # https://github.com/Homebrew/homebrew-core/pull/53489
> + ifeq ($(shell test -d /usr/local/opt/gettext/ && echo y),y)
> + BASIC_CFLAGS += -I/usr/local/include -I/usr/local/opt/gettext/include
> + BASIC_LDFLAGS += -L/usr/local/lib -L/usr/local/opt/gettext/lib
> + ifeq ($(shell test -x /usr/local/opt/gettext/bin/msgfmt && echo y),y)
> + MSGFMT = /usr/local/opt/gettext/bin/msgfmt
> + endif
> + endif
> endif
> ifeq ($(uname_S),SunOS)
> NEEDS_SOCKET = YesPlease
>
since this doesn't depend on NO_GETTEXT and the gettext support doesn't get
automatically configured and used if found (unlike most other) then having
it here could work and is cleaner, but will still mean that MSGFMT will be
called to compile the translation files even when git is built with NO_GETTEXT
just because of that oddity I think having it with the other package related
entries in Makefile might still make sense (specially since we can't get
rid of it unless we also deprecate the other package managers), but if
cleaning it is what you had in mind would also appreciate in that line your
review on 20200425102651.51961-1-carenas@xxxxxxxxx[1] and
20200425091549.42293-1-carenas@xxxxxxxxx[2] that do similar work and that
in the later case improve performance and correctness of git grep.
Carlo
[1] https://lore.kernel.org/git/20200425102651.51961-1-carenas@xxxxxxxxx/
[2] https://lore.kernel.org/git/20200425091549.42293-1-carenas@xxxxxxxxx/
