[Libwebsockets] DLWS_WITH_DISTRO_RECOMMENDED and Fedora

Andy Green andy at warmcat.com
Sun Feb 10 19:39:36 CET 2019



On February 10, 2019 9:24:37 AM PST, Per Bothner <per at bothner.com> wrote:
>To see what happens I tried  $ cmake -DLWS_WITH_DISTRO_RECOMMENDED=1 ..
>
>and got:
>
>...
>libev include dir: LIBEV_INCLUDE_DIRS-NOTFOUND
>libev libraries: LIBEV_LIBRARIES-NOTFOUND
>libuv include dir: /usr/include
>libuv libraries: /usr/lib64/libuv.so
>dbus include dir 1: /usr/include/dbus-1.0
>dbus include dir 2: /usr/lib64/dbus-1.0/include
>-- Looking for SSL_CTX_set1_param
>CMake Error: The following variables are used in this project, but they
>are set to NOTFOUND.
>Please set them or make sure they are set and tested correctly in the
>CMake files:
>LIBEV_LIBRARIES
>linked by target "cmTC_65b86" in directory
>/home/bothner/Software/libwebsockets/build/CMakeFiles/CMakeTmp
>...
>
>This seems familiar to me, though I haven't search the mailing list.
>More importantly, I haven't found a place the the READMEs that explains
>when libev is needs and how to get/enable/disable it, except:

The choice of event loop is either something your application can mandate, or you are trying to work with another project where they already mandated it.  If that project uses libev, lws to work with that must have been built with libev support.  If it's standalone, then the default poll() or platform-specific one is usually enough and no need to care about it.  Basically you will know if you need to consider it.

You'd pick an event loop lib (libuv seems the best bet to me, but it requires some tricky learning) to get abstracted "poll wait" that's the best for the platform, eg, epoll() on linux and whatever on windows.  They also abstract stuff like directory content enumeration on not-really-posix platforms like windows so you can write that code once at the cost of requiring that event lib.

>Distro packagers should select the CMake option
>"LWS_WITH_DISTRO_RECOMMENDED",
>which selects common additional options like support for various event
>libraries,
>     plugins and lwsws.
>
>(Just trying to figure out what the right thing is.  If
>LWS_WITH_DISTRO_RECOMMENDED
>isn't useful to a distro like Fedora for some perceived or real reason,
>that seems non-ideal ...)

If the reasoning there is actually it includes things not needed by the one thing the packager is thinking about that has lws as a dependency, not much I can do about it.

DISTRO_RECOMMENDED is my idea of what many lws users will find useful in a distro packaged version.  But the distro and specifically the individual packaging it may just not care about anything except what they care about and regard lws features they personally don't use as meaningless.  Even the reason they gave about test apps has a way to handle it in packaging semantics, if you believe they are not wholly useless cruft, which is split off a libwebsockets-testapps subpackage.

Lws is highly configurable and the minimum build keeps getting smaller (ability to disable roles and on master now even disable anything regarding sockets and network).  Packagers with one scenario in mind are unfortunately unlikely to step back and think through how all the different things might be useful, and just use the default (which has also been getting smaller over time) with the additional options their scenario needs.  That's why DISTRO_RECOMMENDED came about, to avoid a needlessly "tailored" lws in the distros making it useless for other real scenarios.

Having recently completed a difficult project using lws JOSE with pki, in fact there are no existing JOSE commandline tools (ie, like commandline openssl) I could find other than the lws ones.... but if you don't use JOSE you're free to not care about it.  However for a distro, especially the one I use, I'd've hoped the packager either asked about what's the point of each thing in DISTRO_RECOMMENDED (this is not immutable stuff...) or erred on the side of if it exists and is maintained, it might be useful to users of the distro if not the packager personally.

-Andy


More information about the Libwebsockets mailing list