Johannes Schindelin [off-list ref] writes:
Hi Ævar,
On Fri, 16 Jul 2021, Ævar Arnfjörð Bjarmason wrote:
quoted
On Fri, Jul 16 2021, Johannes Schindelin wrote:
quoted
So you suggest that we name the new stuff after an `uname` that
reflects a name that is no longer relevant? I haven't seen a real
Darwin system in quite a long time, have you?
It's not current? On an Mac Mini M1 which got released this year:
% uname -s
Darwin
We then have the same in config.mak.uname, it seemed the most obvious
and consistent to carry that through to file inclusion.
Sorry. I assumed that you knew that Darwin was the name for an open source
Operating System. See
https://en.wikipedia.org/wiki/Darwin_%28operating_system%29 for more
details.
Ciao,
Johannes
Sorry, but I do not see that you are being more constructive than
the other party, whom you blame to be not constructive, in this
exchange.
The part of the file that the patch applies to uses $(uname_S) to
implement platform specific special cases, and we are looking at
ifeq ($(uname_S),Darwin)
...
FSMONITOR_DAEMON_BACKEND = macos
...
endif
I find it a fair question why the name used there has to be
different from the one we can automatically and mechanically
get out of "uname -s".
Then you respond that uname output is no longer relevant because
Darwin is a name that is no longer relevant? And when asked why the
name is no longer relevant, you make a sniding comment implying that
the other party does not know the name is an operating system?
What is going on here?
It does not really matter how "Darwin" is described in an
encyclopedia in the context of this discussion. What matters is
that it is what the system's "uname -s" currently uses to identify
itself, and what we guard the section of makefile snippet with,
isn't it?
ci/lib.sh seems to have an attempt to unify/translate among these
names, and
* on azure-pipelines, it wants to translate darwin to osx
* on github-actions, it wants to translate macos to osx
Presumably that is because these two systems call the platform with
these two different names, and you want to pick a middle ground that
nobody uses to be neutral, or something?
Also, in contrib/vscode/init.sh, I see Darwin obtained from "uname -s"
gets translated to "macOS".
In any case, if your argument was "we picked macos because we use
the same token elsewhere, while trying to translate away from Darwin
as much as possible for such and such reasons", I would have found
it a productive exchange, but unfortunately that is not what I am
seeing here.
On 7/26/21 7:26 PM, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
Hi Ævar,
On Fri, 16 Jul 2021, Ævar Arnfjörð Bjarmason wrote:
quoted
On Fri, Jul 16 2021, Johannes Schindelin wrote:
...
I'm not sure that there is a "correct" answer here, but for the sake
of harmony, in V4 I'll set this to "darwin" and update the name of
the backend driver source file to match. So that we are consistently
using 1 term throughout "Makefile" and "config.mak.uname".
ifeq ($(uname_S),Darwin)
...
FSMONITOR_DAEMON_BACKEND = darwin
endif
FWIW, I suspect that it is not worth the effort to directly set the
backend name from $(uname_S). For example, on Windows we currently have
two different uname values depending on which compiler is being used.
ifeq ($(uname_S),Windows)
...
FSMONITOR_DAEMON_BACKEND = win32
endif
ifneq (,$(findstring MINGW,$(uname_S)))
...
FSMONITOR_DAEMON_BACKEND = win32
endif
Also, since the backend layer is highly platform-specific, it may be
a while (if ever) before we have universal coverage for all platforms.
Until then, we can simply set $FSMONITOR_DAEMON_BACKEND to a literal
value on a platform-by-platform basis as support is added.
Thanks,
Jeff
On Tue, Jul 27 2021, Jeff Hostetler wrote:
On 7/26/21 7:26 PM, Junio C Hamano wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
Hi Ævar,
On Fri, 16 Jul 2021, Ævar Arnfjörð Bjarmason wrote:
quoted
On Fri, Jul 16 2021, Johannes Schindelin wrote:
...
I'm not sure that there is a "correct" answer here, but for the sake
of harmony, in V4 I'll set this to "darwin" and update the name of
the backend driver source file to match. So that we are consistently
using 1 term throughout "Makefile" and "config.mak.uname".
ifeq ($(uname_S),Darwin)
...
FSMONITOR_DAEMON_BACKEND = darwin
endif
FWIW, I suspect that it is not worth the effort to directly set the
backend name from $(uname_S). For example, on Windows we currently have
two different uname values depending on which compiler is being used.
ifeq ($(uname_S),Windows)
...
FSMONITOR_DAEMON_BACKEND = win32
endif
ifneq (,$(findstring MINGW,$(uname_S)))
...
FSMONITOR_DAEMON_BACKEND = win32
endif
Also, since the backend layer is highly platform-specific, it may be
a while (if ever) before we have universal coverage for all platforms.
Until then, we can simply set $FSMONITOR_DAEMON_BACKEND to a literal
value on a platform-by-platform basis as support is added.
Re "harmony": For what it's worth I don't think you should change it on
my accord.
I should probably have more explicitly said (but I've also been trying
to check the general verbosity of my E-Mails), that when I read a series
like this and have some general trivial comments like this, I mean them
as something like:
Just a thought while reading this through, i.e. a person familiar
with the general codebase but not necessarily your specific
are. Maybe this suggestion makes things easier/simpler, but if you
think not and decide not to take the suggestion that's fine too.
I.e. that along with the general implicit suggestion that I'd say
applies in general on list that if someone is perplexed by a patch by
default that's a comment on the commit message.
That person (i.e. me in this case) could also just be hopelessly
confused & nothing needs to change. When I get comments like that I
sometimes change things, sometimes not. You should do the same.
As noted in another reply on this general thread & what's cooking I seem
to have poked a bit of a hornet's nest here that I wasn't expecting to
poke. I'd not been following earlier rounds of this topic, and didn't
know that it had (seemingly) reached some phase of critical updates only
in the minds of its authors.