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

> 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@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?