c6c7ab2b44
Event lib support as it has been isn't scaling well, at the low level libevent and libev headers have a namespace conflict so they can't both be built into the same image, and at the distro level, binding all the event libs to libwebsockets.so makes a bloaty situation for packaging, lws will drag in all the event libs every time. This patch implements the plan discussed here https://github.com/warmcat/libwebsockets/issues/1980 and refactors the event lib support so they are built into isolated plugins and bound at runtime according to what the application says it wants to use. The event lib plugins can be packaged individually so that only the needed sets of support are installed (perhaps none of them if the user code is OK with the default poll() loop). And dependent user code can mark the specific event loop plugin package as required so pieces are added as needed. The eventlib-foreign example is also refactored to build the selected lib support isolated. A readme is added detailing the changes and how to use them. https://libwebsockets.org/git/libwebsockets/tree/READMEs/README.event-libs.md
3.2 KiB
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.