mirror of
https://github.com/warmcat/libwebsockets.git
synced 2025-03-09 00:00:04 +01:00
81 lines
3.2 KiB
Markdown
81 lines
3.2 KiB
Markdown
![]() |
# lws event library support
|
||
|
|
||
|
## v4.0 and below
|
||
|
|
||
|
Before v4.1, lws allowed selecting some event library support for inclusion
|
||
|
in the libwebsockets library
|
||
|
|
||
|
Option|Feature
|
||
|
---|---
|
||
|
`LWS_WITH_GLIB`|glib
|
||
|
`LWS_WITH_LIBEVENT`|libevent
|
||
|
`LWS_WITH_LIBUV`|libuv
|
||
|
`LWS_WITH_LIBEV`|libev
|
||
|
|
||
|
The user code can select by `info->options` flags at runtime which event loop
|
||
|
it wants to use.
|
||
|
|
||
|
The only restriction is that libev and libevent can't coexist, because their
|
||
|
header namespace conflicts.
|
||
|
|
||
|
## v4.1 and above
|
||
|
|
||
|
Lws continues to support the old way described above, but there's an additional
|
||
|
new cmake option that decides how they are built if any are selected,
|
||
|
`LWS_WITH_EVLIB_PLUGINS`.
|
||
|
|
||
|
The old behaviour is set by `LWS_WITH_EVLIB_PLUGINS=0`, for UNIX platforms, this
|
||
|
is set to 1 by default. This causes the enabled event lib support to each be built into
|
||
|
its own dynamically linked plugin, and lws will bring in the requested support alone
|
||
|
at runtime after seeing the `info->options` flags requested by the user code.
|
||
|
|
||
|
This has two main benefits, first the conflict around building libevent and libev
|
||
|
together is removed, they each build isolated in their own plugin; the libwebsockets
|
||
|
core library build doesn't import any of their headers (see below for exception).
|
||
|
And second, for distro packaging, the event lib support plugins can be separately
|
||
|
packaged, and apps take dependencies on the specific event lib plugin package, which
|
||
|
itself depends on the libwebsockets core library. This allows just the needed
|
||
|
dependencies for the packageset without forcing everything to bring everything in.
|
||
|
|
||
|
Separately, lws itself has some optional dependencies on libuv, if you build lwsws
|
||
|
or on Windows you want plugins at all. CMake will detect these situations and
|
||
|
select to link the lws library itself to libuv if so as well, independent of whatever
|
||
|
is happening with the event lib support.
|
||
|
|
||
|
## evlib plugin install
|
||
|
|
||
|
The produced plugins are named
|
||
|
|
||
|
event lib|plugin name
|
||
|
---|---
|
||
|
glib|`libwebsockets-evlib_glib.so`
|
||
|
event|`libwebsockets-evlib_event.so`
|
||
|
uv|`libwebsockets-evlib_uv.so`
|
||
|
ev|`libwebsockets-evlib_ev.so`
|
||
|
|
||
|
The evlib plugins are installed alongside libwebsockets.so/.a into the configured
|
||
|
library dir, it's often `/usr/local/lib/` by default on linux.
|
||
|
|
||
|
Lws looks for them at runtime using the build-time-configured path.
|
||
|
|
||
|
## Component packaging
|
||
|
|
||
|
The canonical package name is `libwebsockets`, the recommended way to split the
|
||
|
packaging is put the expected libs and pkgconfig in `libwebsockets` or `libwebsockets-core`,
|
||
|
the latter is followed by the provided cmake, and produce an additional package per build
|
||
|
event library plugin, named, eg `libwebsockets-evlib_glib`, which has a dependency on
|
||
|
`libwebsockets[-core]`.
|
||
|
|
||
|
Applications that use the default event loop can directly require `libwebsockets[-core]`,
|
||
|
and application packages that need specific event loop support can just require, eg,
|
||
|
`libwebsockets-evlib_glib`, which will bring that in and the core lws pieces in one step.
|
||
|
There is then no problem with multiple apps requiring different event libs, they will
|
||
|
bring in all the necessary pieces which will not conflict either as packages or at
|
||
|
runtime.
|
||
|
|
||
|
## `LWS_WITH_DISTRO_RECOMMENDED`
|
||
|
|
||
|
The cmake helper config `LWS_WITH_DISTRO_RECOMMENDED` is adapted to build all the
|
||
|
event libs with the event lib plugin support enabled.
|
||
|
|