--- EV/Makefile.PL	2007/11/22 04:52:24	1.23
+++ EV/Makefile.PL	2008/04/15 04:41:57	1.33
@@ -40,7 +40,8 @@
 reliably. Unfortunately, some systems are bound to be broken, so you can
 disable this here: you can completely disable the detection and use of
 the monotonic clock by answering 'n' here. Support for this clock type
-will otherwise be autodetected at both compile- and runtime.
+will otherwise be autodetected at both compile- and runtime. (this setting
+currently affects the use of nanosleep over select as well).
 
 EOF
 
@@ -67,6 +68,21 @@
 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
 
 
+Another useful bit of functionality is the Linux eventfd, which is useful
+for faster signal handling (don't care) and intra-thread communications
+(mostly useful for embedding). Kernel support for this will be probed at
+runtime, but your libc must contain the necessary wrapper. Glibc 2.7 and
+later should have this wrapper.
+
+EOF
+
+$DEFINE .= " -DEV_USE_EVENTFD=" . (0 + (prompt ("Enable linux eventfd support (y/n)?", (-e "/usr/include/sys/eventfd.h") || $ENV{EV_EVENTFD} ? "y" : "n") =~ /[yY]/));
+
+print <<EOF;
+
+*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
+
+
 EV can use various backends with various portability issue. The select
 backend is the most portable and makes for a good fallback, but it can be
 limited to a low number of file descriptors and/or might not compile. If
@@ -118,13 +134,13 @@
 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
 
 
-EV by default uses select, which makes it hard to write efficient servers,
-especially if the number of active connections is much lower than the open
-ones. GNU/Linux systems have a more scalable method called "epoll", which
-EV can use. For this to work, both your kernel and glibc have to support
-epoll, but if you can compile it, the detection will be done at runtime,
-and EV will safely fall back to using select when epoll isn't available.
-If unsure, accept the default.
+Select and poll make it hard to write efficient servers, especially if the
+number of active connections is much lower than the watched ones. GNU/Linux
+systems have a more scalable method called "epoll", which EV can use. For
+this to work, both your kernel and glibc have to support epoll, but if you
+can compile it, the detection will be done at runtime, and EV will safely
+fall back to using select when epoll isn't available. If unsure, accept
+the default.
 
 EOF
 
@@ -139,19 +155,22 @@
 many BSD systems. Support for kqueue will be detected at runtime, with a
 safe fallback to other methods when it cannot be used.
 
-Note that kqueue is broken on most operating systems, so it defaults to
-'n' on most platforms that claim to support it. Here is what we know:
-
-OS X:    completely, utterly broken on at least <= 10.5.
-FreeBSD: broken on at least <= 6.2-STABLE,
-         sockets and pipes *might* work, ptys definitely don't.
-NetBSD:  reports indicate that it likely WORKS. Yeah! :)
+Note that kqueue is broken on most operating systems, so by default it
+won't be used on many platforms, but you can still create your own event
+loop with qkueue backend.
+
+Here is what we know:
+
+NetBSD:  partially working in at least 3.1. Yeah! :)
+FreeBSD: broken on at least 6.2-STABLE,
+         sockets *likely* work, ptys definitely don't.
 OpenBSD: reports indicate that it likely doesn't work
          (similar problems as on FreeBSD).
+OS X:    completely, utterly broken on at least < 10.5.
 
 EOF
 
-my $can_kqueue = $^O =~ /netbsd/i && -e "/usr/include/sys/event.h";
+my $can_kqueue = -e "/usr/include/sys/event.h";
 
 $DEFINE .= " -DEV_USE_KQUEUE=" . (0 + (prompt ("Enable kqueue backend (y/n)?", $can_kqueue ? "y" : "n") =~ /[yY]/));
 
@@ -161,12 +180,12 @@
 
 
 Similarly to the kqueue backend above, EV can take advantage of the
-solaris 10 port interface. Support for port will be detected at runtime,
-with a safe fallback to other methods when it cannot be used.
+solaris 10 event port interface. Support for event ports will be detected
+at runtime, with a safe fallback to other methods when it cannot be used.
 
 EOF
 
-$DEFINE .= " -DEV_USE_PORT=" . (0 + (prompt ("Enable port backend (y/n)?", (-e "/usr/include/sys/port.h") ? "y" : "n") =~ /[yY]/));
+$DEFINE .= " -DEV_USE_PORT=" . (0 + (prompt ("Enable event port backend (y/n)?", (-e "/usr/include/sys/port.h") ? "y" : "n") =~ /[yY]/));
 
 print <<EOF;
 
@@ -190,6 +209,21 @@
 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
 
 
+A backend of a different kind is the Linux inotify(7) interface, which can
+be used to speed up (and reduce resource consumption) of stat watchers. If
+you have it, it is usually a good idea to enable it.
+
+EOF
+
+my $can_inotify = -e "/usr/include/sys/inotify.h";
+
+$DEFINE .= " -DEV_USE_INOTIFY=" . (0 + (prompt ("Enable inotify support (y/n)?", $can_inotify ? "y" : "n") =~ /[yY]/));
+
+print <<EOF;
+
+*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
+
+
 EOF
 
 my @anyevent = eval { require AnyEvent; $AnyEvent::VERSION < 2.6 } ? (AnyEvent => 2.6) : ();
@@ -203,7 +237,7 @@
     depend => {
        "EV.c" => "EV/EVAPI.h "
                . "libev/ev.c libev/ev.h libev/ev_epoll.c libev/ev_select.c libev/ev_kqueue.c libev/ev_poll.c "
-               . "libev/event.h libev/event.c evdns.h evdns.c libev/ev_vars.h libev/ev_wrap.h",
+               . "libev/ev_vars.h libev/ev_wrap.h",
     },
     INC       => "-Ilibev",
     DEFINE    => "$DEFINE",
@@ -215,7 +249,6 @@
     VERSION_FROM => "EV.pm",
     PM           => {
     		    'EV.pm'		=> '$(INST_LIBDIR)/EV.pm',
-                    'EV/DNS.pm'		=> '$(INST_LIBDIR)/EV/DNS.pm',
     		    'EV/EVAPI.h'	=> '$(INST_LIBDIR)/EV/EVAPI.h',
     		    'EV/MakeMaker.pm'	=> '$(INST_LIBDIR)/EV/MakeMaker.pm',
     		    'libev/ev.h'	=> '$(INST_LIBDIR)/EV/ev.h',