Re: [PATCH v3 12/34] fsmonitor-fs-listen-macos: stub in backend for MacOS
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jul 16, 2021, 15:51 UTC
- Message-ID
- <nycvar.QRO.7.76.6.2107161748050.59@tvgsbejvaqbjf.bet>
- In-Reply-To
- <87sg0xbq9v.fsf@evledraar.gmail.com>
Hi Ævar,
On Fri, 2 Jul 2021, Ævar Arnfjörð Bjarmason wrote:
Show 58 quoted lines
> On Thu, Jul 01 2021, Jeff Hostetler via GitGitGadget wrote:
>
> > From: Jeff Hostetler <jeffhost@microsoft.com>
> >
> > Stub in empty implementation of fsmonitor--daemon
> > backend for MacOS.
> >
> > Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
> > ---
> > compat/fsmonitor/fsmonitor-fs-listen-macos.c | 20 ++++++++++++++++++++
> > config.mak.uname | 2 ++
> > contrib/buildsystems/CMakeLists.txt | 3 +++
> > 3 files changed, 25 insertions(+)
> > create mode 100644 compat/fsmonitor/fsmonitor-fs-listen-macos.c
> >
> > diff --git a/compat/fsmonitor/fsmonitor-fs-listen-macos.c b/compat/fsmonitor/fsmonitor-fs-listen-macos.c
> > new file mode 100644
> > index 00000000000..b91058d1c4f
> > --- /dev/null
> > +++ b/compat/fsmonitor/fsmonitor-fs-listen-macos.c
> > @@ -0,0 +1,20 @@
> > +#include "cache.h"
> > +#include "fsmonitor.h"
> > +#include "fsmonitor-fs-listen.h"
> > +
> > +int fsmonitor_fs_listen__ctor(struct fsmonitor_daemon_state *state)
> > +{
> > + return -1;
> > +}
> > +
> > +void fsmonitor_fs_listen__dtor(struct fsmonitor_daemon_state *state)
> > +{
> > +}
> > +
> > +void fsmonitor_fs_listen__stop_async(struct fsmonitor_daemon_state *state)
> > +{
> > +}
> > +
> > +void fsmonitor_fs_listen__loop(struct fsmonitor_daemon_state *state)
> > +{
> > +}
> > diff --git a/config.mak.uname b/config.mak.uname
> > index fcd88b60b14..394355463e1 100644
> > --- a/config.mak.uname
> > +++ b/config.mak.uname
> > @@ -147,6 +147,8 @@ ifeq ($(uname_S),Darwin)
> > MSGFMT = /usr/local/opt/gettext/bin/msgfmt
> > endif
> > endif
> > + FSMONITOR_DAEMON_BACKEND = macos
>
> A rather trivial point, but can't we pick one of "macos" or "darwin"
> (I'd think going with the existing uname is better) and name the file
> after the uname (or lower-case thereof)?
>
> Makes these make rules more consistent too, we could just set this to
> "YesPlease" here, and then lower case the uname for the file
> compilation/include.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?
I don't find such a suggestion constructive, I have to admit.
Ciao, Johannes