...

* Building libevent as a sub-project using GNU Auto* tools

Some projects will choose to include libevent in their source distribution,
and build libevent as a sub-project.  This may be effected by putting the
line:

 AC_CONFIG_SUBDIRS([path/to/libevent])

in the master configure.ac file for the master project.

There are cases where the master project will want to pass in additional
flags for CFLAGS, CPPFLAGS, or LDFLAGS.  Since these variables are reserved
for the user, and AM_CFLAGS, AM_CPPFLAGS, and AM_LDFLAGS are reserved for
each package, libevent offers the following variables for a master package
to tell libevent that there are additional compile/link values:

 LIBEVENT_CFLAGS
 LIBEVENT_CPPFLAGS
 LIBEVENT_LDFLAGS

A master package can set these variables in its configure.ac file.

Here's an example:

configure.ac:
...
EXTRA_CFLAGS=...
EXTRA_CPPFLAGS=...
EXTRA_LDFLAGS=...
...
dnl ac_configure_args is undocumented but widely abused, as here,
dnl to modify the defaults of the libevent subpackage, by prefixing
dnl our changes to the child configure arguments already assembled.
dnl User-supplied contradictory choices should prevail thanks to
dnl "last wins".
ac_configure_args=" --disable-openssl${ac_configure_args}"
ac_configure_args=" --disable-shared${ac_configure_args}"
ac_configure_args=" --disable-libevent-regress${ac_configure_args}"
ac_configure_args=" --disable-libevent-install${ac_configure_args}"
ac_configure_args=" --enable-silent-rules${ac_configure_args}"
ac_configure_args=" --enable-function-sections${ac_configure_args}"
ac_configure_args=" LIBEVENT_CFLAGS='${EXTRA_CFLAGS}'${ac_configure_args}"
ac_configure_args=" LIBEVENT_CPPFLAGS='${EXTRA_CPPFLAGS}'${ac_configure_args}"
ac_configure_args=" LIBEVENT_LDFLAGS='${EXTRA_LDFLAGS}'${ac_configure_args}"
AC_CONFIG_SUBDIRS([libevent])
...

The space after the initial '"' is significant.

* "Prepare" and "check" watchers

Libevent now has a new mechanism for hooking into the event loop: "prepare" and
"check" watchers.  A "prepare" watcher is a callback that fires immediately
before polling for I/O. A "check" watcher is a callback that fires immediately
after polling and before processing any active events. This may be useful for
embedding other libraries' event loops (e.g. UI toolkits) into libevent's. It's
also useful for monitoring server performance. For example, if you measure the
time between "prepare" and "check," that is the polling duration; the difference
between the expected and actual polling duration provides an indication of
kernel scheduling delay. And if you measure the time between "check" and the
next "prepare" (in the next iteration of the event loop), that is a good
approximation of the amount of time handling events; this provides a convenient
way to monitor whether any event handlers are blocking or otherwise performing
heavy computation.

The watcher API is defined in <event2/watch.h>. A concrete example of how
watchers can help monitor server performance is available in
"sample/watch-timing.c".

* Support for custom HTTP methods

Libevent HTTP code now supports defining custom HTTP methods. It is done
through a callback:

  #define EVHTTP_REQ_CUSTOM      ((EVHTTP_REQ_MAX) << 1)
  static int ext_method_cb(struct evhttp_ext_method *p)
  {
    if (p == NULL)
      return -1;
    if (p->method) {
      if (strcmp(p->method, "CUSTOM") == 0) {
        p->type = EVHTTP_REQ_CUSTOM;
        p->flags = 0;   /*EVHTTP_METHOD_HAS_BODY*/
        return 0;
      }
    } else {
      if (p->type == EVHTTP_REQ_CUSTOM) {
        p->method = "CUSTOM";
        return 0;
      }
    }
  }

And to register this callback with http server you can use:
  evhttp_set_ext_method_cmp(http, ext_method_cb);

Or registering callback with one client only:
  evhttp_connection_set_ext_method_cmp(evcon, ext_method_cb);