Browse Source

include embedding doc in main doc

tags/rel-1.3
Marc Alexander Lehmann 12 years ago
parent
commit
201408b2a8
4 changed files with 12 additions and 252 deletions
  1. +2
    -234
      README.embed
  2. +7
    -15
      ev.3
  3. +2
    -2
      ev.html
  4. +1
    -1
      ev.pod

+ 2
- 234
README.embed View File

@@ -1,235 +1,3 @@
EMBEDDING THE LIBEV CODE INTO YOUR OWN PROGRAMS

Instead of building the libev library you can also include the code
as-is into your programs. To update, you only have to copy a few files
into your source tree.

This is how it works:

FILESETS

CORE EVENT LOOP

To include only the libev core (all the ev_* functions):

#define EV_STANDALONE 1
#include "ev.c"

This will automatically include ev.h, too, and should be done in a
single C source file only to provide the function implementations. To
use it, do the same for ev.h in all files wishing to use this API
(best done by writing a wrapper around ev.h that you can include
instead and where you can put other configuration options):

#define EV_STANDALONE 1
#include "ev.h"

Both header files and implementation files can be compiled with a C++
compiler (at least, thats a stated goal, and breakage will be treated
as a bug).

You need the following files in your source tree, or in a directory
in your include path (e.g. in libev/ when using -Ilibev):

ev.h
ev.c
ev_vars.h
ev_wrap.h

ev_win32.c required on win32 platforms only

ev_select.c only when select backend is enabled (which is is by default)
ev_poll.c only when poll backend is enabled (disabled by default)
ev_epoll.c only when the epoll backend is enabled (disabled by default)
ev_kqueue.c only when the kqueue backend is enabled (disabled by default)
ev_port.c only when the solaris port backend is enabled (disabled by default)

"ev.c" includes the backend files directly when enabled.

LIBEVENT COMPATIBILITY API

To include the libevent compatibility API, also include:

#include "event.c"

in the file including "ev.c", and:

#include "event.h"

in the files that want to use the libevent API. This also includes "ev.h".

You need the following additional files for this:

event.h
event.c

AUTOCONF SUPPORT

Instead of using EV_STANDALONE=1 and providing your config in whatever
way you want, you can also m4_include([libev.m4]) in your configure.ac
and leave EV_STANDALONE off. ev.c will then include "config.h" and
configure itself accordingly.

PREPROCESSOR SYMBOLS

Libev can be configured via a variety of preprocessor symbols you have to define
before including any of its files. The default is not to build for multiplicity
and only include the select backend.

EV_STANDALONE

Must always be "1", which keeps libev from including config.h or
other files, and it also defines dummy implementations for some
libevent functions (such as logging, which is not supported). It
will also not define any of the structs usually found in "event.h"
that are not directly supported by libev code alone.

EV_USE_MONOTONIC

If defined to be "1", libev will try to detect the availability
of the monotonic clock option at both compiletime and
runtime. Otherwise no use of the monotonic clock option will be
attempted. If you enable this, you usually have to link against
librt or something similar. Enabling it when the functionality
isn't available is safe, though.

EV_USE_REALTIME

If defined to be "1", libev will try to detect the availability
of the realtime clock option at compiletime (and assume its
availability at runtime if successful). Otherwise no use of the
realtime clock option will be attempted. This effectively replaces
gettimeofday by clock_get (CLOCK_REALTIME, ...) and will not normally
affect correctness.

EV_USE_SELECT

If undefined or defined to be "1", libev will compile in support
for the select(2) backend. No attempt at autodetection will be
done: if no other method takes over, select will be it. Otherwise
the select backend will not be compiled in.

EV_SELECT_USE_FD_SET

If defined to 1, then the select backend will use the system fd_set
structure. This is useful if libev doesn't compile due to a missing
NFDBITS or fd_mask definition or it misguesses the bitset layout on
exotic systems. This usually limits the range of file descriptors
to some low limit such as 1024 or might have other limitations
(winsocket only allows 64 sockets). The FD_SETSIZE macro, set
before compilation, might influence the size of the fd_set used.

EV_SELECT_IS_WINSOCKET

When defined to 1, the select backend will assume that
select/socket/connect etc. don't understand file descriptors but
wants osf handles on win32 (this is the case when the select to
be used is the winsock select). This means that it will call
_get_osfhandle on the fd to convert it to an OS handle. Otherwise,
it is assumed that all these functions actually work on fds, even
on win32. Should not be defined on non-win32 platforms.

EV_USE_POLL

If defined to be "1", libev will compile in support for the poll(2)
backend. Otherwise it will be enabled on non-win32 platforms. It
takes precedence over select.

EV_USE_EPOLL

If defined to be "1", libev will compile in support for the Linux
epoll backend. Its availability will be detected at runtime,
otherwise another method will be used as fallback. This is the
preferred backend for GNU/Linux systems.

EV_USE_KQUEUE

If defined to be "1", libev will compile in support for the BSD
style kqueue backend. Its availability will be detected at runtime,
otherwise another method will be used as fallback. This is the
preferred backend for BSD and BSD-like systems. Darwin brokenness
will be detected at runtime and routed around by disabling this
backend.

EV_USE_PORT

If defined to be "1", libev will compile in support for the Solaris
10 port style backend. Its availability will be detected at runtime,
otherwise another method will be used as fallback. This is the
preferred backend for Solaris 10 systems.

EV_USE_DEVPOLL
reserved for future expansion, works like the USE symbols above.

EV_H

The name of the ev.h header file used to include it. The default
if undefined is <ev.h> in event.h and "ev.h" in ev.c. This can
be used to virtually rename the ev.h header file in case of
conflicts.

EV_CONFIG_H

If EV_STANDALONE isn't 1, this variable can be used to override
ev.c's idea of where to find the "config.h" file.

EV_EVENT_H

Similarly to EV_H, this macro can be used to override event.c's idea
of how the event.h header can be found.

EV_PROTOTYPES

If defined to be "0", then "ev.h" will not define any function
prototypes, but still define all the structs and other
symbols. This is occasionally useful.

EV_MULTIPLICITY

If undefined or defined to "1", then all event-loop-specific
functions will have the "struct ev_loop *" as first argument, and
you can create additional independent event loops. Otherwise there
will be no support for multiple event loops and there is no first
event loop pointer argument. Instead, all functions act on the
single default loop.

EV_PERIODICS

If undefined or defined to be "1", then periodic timers are
supported, otherwise not. This saves a few kb of code.

EV_COMMON
By default, all watchers have a "void *data" member. By redefining
this macro to a something else you can include more and other types
of members. You have to define it each time you include one of the
files, though, and it must be identical each time.

For example, the perl EV module uses this:

#define EV_COMMON \
SV *self; /* contains this struct */ \
SV *cb_sv, *fh /* note no trailing ";" */

EV_CB_DECLARE(type)
EV_CB_INVOKE(watcher,revents)
ev_set_cb(ev,cb)

Can be used to change the callback member declaration in each
watcher, and the way callbacks are invoked and set. Must expand
to a struct member definition and a statement, respectively. See
the ev.v header file for their default definitions. One possible
use for overriding these is to avoid the ev_loop pointer as first
argument in all cases, or to use method calls instead of plain
function calls in C++.

EXAMPLES

For a real-world example of a program the includes libev
verbatim, you can have a look at the EV perl module
(http://software.schmorp.de/pkg/EV.html). It has the libev files in
the libev/ subdirectory and includes them in the EV/EVAPI.h (public
interface) and EV.xs (implementation) files. Only the EV.xs file will
be compiled.
This file is now included in the main libev documentation, see

http://cvs.schmorp.de/libev/ev.html

+ 7
- 15
ev.3 View File

@@ -1799,29 +1799,21 @@ The usage in rxvt-unicode is simpler. It has a \fIev_cpp.h\fR header file
that everybody includes and which overrides some autoconf choices:
.Sp
.Vb 4
\& #define EV_USE_POLL 0
\& #define EV_MULTIPLICITY 0
\& #define EV_PERIODICS 0
\& #define EV_CONFIG_H <config.h>
\& #define EV_USE_POLL 0
\& #define EV_MULTIPLICITY 0
\& #define EV_PERIODICS 0
\& #define EV_CONFIG_H <config.h>
.Ve
.Sp
.Vb 1
\& #include "ev++.h"
\& #include "ev++.h"
.Ve
.Sp
And a \fIev_cpp.C\fR implementation file that contains libev proper and is compiled:
.Sp
.Vb 1
\& #include "rxvttoolkit.h"
.Ve
.Sp
.Vb 2
\& /* darwin has problems with its header files in C++, requiring this namespace juggling */
\& using namespace ev;
.Ve
.Sp
.Vb 1
\& #include "ev.c"
\& #include "ev_cpp.h"
\& #include "ev.c"
.Ve
.SH "AUTHOR"
.IX Header "AUTHOR"


+ 2
- 2
ev.html View File

@@ -6,7 +6,7 @@
<meta name="description" content="Pod documentation for libev" />
<meta name="inputfile" content="&lt;standard input&gt;" />
<meta name="outputfile" content="&lt;standard output&gt;" />
<meta name="created" content="Sat Nov 24 11:15:15 2007" />
<meta name="created" content="Sat Nov 24 11:19:13 2007" />
<meta name="generator" content="Pod::Xhtml 1.57" />
<link rel="stylesheet" href="http://res.tst.eu/pod.css"/></head>
<body>
@@ -1585,7 +1585,7 @@ backend for BSD and BSD-like systems, although on most BSDs kqueue only
supports some types of fds correctly (the only platform we found that
supports ptys for example was NetBSD), so kqueue might be compiled in, but
not be used unless explicitly requested. The best way to use it is to find
out wether kqueue supports your type of fd properly and use an embedded
out whether kqueue supports your type of fd properly and use an embedded
kqueue loop.</p>
</dd>
<dt>EV_USE_PORT</dt>


+ 1
- 1
ev.pod View File

@@ -1585,7 +1585,7 @@ backend for BSD and BSD-like systems, although on most BSDs kqueue only
supports some types of fds correctly (the only platform we found that
supports ptys for example was NetBSD), so kqueue might be compiled in, but
not be used unless explicitly requested. The best way to use it is to find
out wether kqueue supports your type of fd properly and use an embedded
out whether kqueue supports your type of fd properly and use an embedded
kqueue loop.

=item EV_USE_PORT


Loading…
Cancel
Save