Re: [PATCH v3 12/34] fsmonitor-fs-listen-macos: stub in backend for MacOS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Ævar,

On Fri, 2 Jul 2021, Ævar Arnfjörð Bjarmason wrote:

> On Thu, Jul 01 2021, Jeff Hostetler via GitGitGadget wrote:
>
> > From: Jeff Hostetler <jeffhost@xxxxxxxxxxxxx>
> >
> > Stub in empty implementation of fsmonitor--daemon
> > backend for MacOS.
> >
> > Signed-off-by: Jeff Hostetler <jeffhost@xxxxxxxxxxxxx>
> > ---
> >  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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux