Re: Using glib's g_file_monitor_file and g_file_monitor_directory

[Eli Zaretskii]

> From: Michael Albinus <address@hidden>
> Date: Tue, 28 May 2013 12:39:15 +0200
> Cc: address@hidden
> 
> I've appended a patch which I have tested successfully under GNU/Linux.
> There is a new gfilenotify.c, which uses glib's functionality.

Thanks.

> There is
> also a new config option --with-file-notification=LIB, LIB can be "yes",
> "no", "gfile" or "inotify". Default on non-w32 machines is "gfile" if
> applicable. For w32 machines, this option is not taken into account yet,
> emacs undonditionally links w32notify (maybe we want also support "no"
> there?).

I'd rather not special-case w32 unless really necessary.  (The whole
point of using the Posix configury was to remove as much w32-specific
stuff as possible from the build process.)  So yes, let's by all means
support "no" for w32, although I'm not sure who'd want that.  And
please also include mingw32 in the same test harness where you test
for gfilenotify and inotify, i.e. test for a header (windows.h will
do), not the value of $opsys.

Btw, glib is available for Windows as well, and AFAICT its
gfilemonitor should work (it actually uses the same APIs as
w32notify.c does).  So "gfile" should not be precluded from the w32
build.

> +if "${opsys}" = "mingw32"; then
> +   NOTIFY_OBJ=w32notify.o
> +   NOTIFY_SUMMARY="yes"
> +fi

See above: I'd prefer this to be a real test, based on windows.h
presence.  And if the user selected "gfile", let them have it, do not
override with w32notify.o.

> +#if defined (HAVE_GFILENOTIFY) || defined (HAVE_INOTIFY) || defined 
> (HAVE_NTGUI)

It sounds like a single symbol HAVE_FILE_NOTIFY, defined somewhere as
the OR of these 3, should make the sources more readable.