From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Carlo Arenas <carenas@gmail.com>
Cc: "Eric Sunshine" <sunshine@sunshineco.com>,
"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>,
"Git List" <git@vger.kernel.org>,
"SZEDER Gábor" <szeder.dev@gmail.com>
Subject: Re: [PATCH] macos: do let the build find the gettext headers/libraries/msgfmt
Date: Sun, 26 Apr 2020 18:59:04 +0200 (CEST) [thread overview]
Message-ID: <nycvar.QRO.7.76.6.2004261856500.18039@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <CAPUEspiici3-tTTe=AWcNWgS4CN8OiqtaE46dQGcNW5weFC8Aw@mail.gmail.com>
Hi Carlo,
On Sun, 26 Apr 2020, Carlo Arenas wrote:
> On Sat, Apr 25, 2020 at 5:59 AM Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Thu, 23 Apr 2020, Eric Sunshine wrote:
> >
> > > On Thu, Apr 23, 2020 at 12:17 PM Eric Sunshine <sunshine@sunshineco.com> wrote:
> > > > I'm slightly leery of seeing these applied globally on Mac OS in
> > > > config.mak.uname since various package managers on Mac OS install
> > > > packages in wildly different locations, and these settings might
> > > > cause the wrong version of a package to be picked up if a user has
> > > > a preferred version installed elsewhere.
> > >
> > > As a follow up, although slightly leery of applying this change
> > > globally to config.mak.uname, I don't necessarily oppose it either.
> > > Considering how widely adopted Homebrew is on Mac OS, baking in a
> > > bit of Homebrew-specific knowledge would make it easier for a Git
> > > developer to get up and running by eliminating some of the manual
> > > fiddling and configuration currently necessary.
> >
> > I share your concern. But in contrast to Fink and DarwinPorts, we have
> > no Homebrew-specific knob in the Makefile (does this mean that we
> > expect users to use Homebrew by default?).
>
> IMHO the reason why there is no NO_BREW flag is because brew decided to
That is not an opinion, but an assumption.
> use the "default" directory instead of one of their own (which is why it
> has so many issues with unlinked files that might or not conflict with
> the system, like gettext), this is also why a NO_BREW flag (similar to
> the other two introduced since 8eb38cad44 (Disable linking with Fink or
> DarwinPorts., 2006-07-24)) wouldn't make sense.
>
> my assumption is also that most people in macOS use brew nowadays
Yes, that is an assumption. One I share, but I would say that it is more a
suspicion because I do not really want to act on it.
> instead of fink, darwinports or any of the other alternatives, but there
> is also people that use none and it is that complication why my proposed
> patch was in what would seem like the wrong place to begin with. for
> more context in that last point see: 59f8674006 (Move Fink and Ports
> check to after config file, 2006-12-12).
>
> on that last point, I am afraid there is still at least a problem that
> needs addressing, but will comment in patch instead for easy of
> reference.
I would have preferred a straight answer right here than a reference to
something I have not received (yet?).
Ciao,
Dscho
next prev parent reply other threads:[~2020-04-26 16:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-23 7:52 [PATCH] macos: do let the build find the gettext headers/libraries/msgfmt Johannes Schindelin via GitGitGadget
2020-04-23 16:17 ` Eric Sunshine
2020-04-23 20:49 ` Eric Sunshine
2020-04-25 12:54 ` Johannes Schindelin
2020-04-26 15:54 ` Carlo Arenas
2020-04-26 16:59 ` Johannes Schindelin [this message]
2020-04-25 6:15 ` [PATCH] macos: do not assume brew and gettext are always available/wanted Carlo Marcelo Arenas Belón
2020-04-25 12:33 ` Johannes Schindelin
2020-04-25 12:54 ` [PATCH v2] macos: do let the build find the gettext headers/libraries/msgfmt Johannes Schindelin via GitGitGadget
2020-04-26 17:05 ` Torsten Bögershausen
2020-04-26 17:34 ` Carlo Marcelo Arenas Belón
2020-04-26 20:09 ` [PATCH v3 1/1] MacOs/brew: Let the build find " tboegi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=nycvar.QRO.7.76.6.2004261856500.18039@tvgsbejvaqbjf.bet \
--to=johannes.schindelin@gmx.de \
--cc=carenas@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=sunshine@sunshineco.com \
--cc=szeder.dev@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).