[Libwebsockets] Release policy [was] 答复: A question about libwebsockets dns resolve and newest tag

Andy Green andy at warmcat.com
Wed May 6 19:41:34 CEST 2020



On 5/6/20 6:19 PM, Jaco Kroon wrote:
> Hi Andy,
> 
> Thank you for a comprehensive response, I appreciate that.  I'll have to
> munch on that for a bit.  I've missed the release policy document
> somewhere along my search, I'll go look again.
> 
> On 2020/05/06 14:11, Andy Green wrote:
> 
>> Something else, what's your opinion about CPack?  In the last days I
>> added artifact support to Sai and at least in the "distro-recommended"
>> build it now produces .deb / .rpm packages.  Does this have any legs
>> in terms of helping / aligning with your distro packaging?
> 
> I've never used CPack, then again, I've not worked much with cmake
> before lws either.
> 
> I'm working on Gentoo, where we package using "ebuild".  This is fairly
> flexible and I can even import rpms or debs from other distributions by
> unpacking and cloning into a staging install dir without much effort,
> although the general style is ./configure && make && make install
> DESTDIR=/path/to/staging_dir all hapening in a sandbox to prevent writes
> outside the temp build dirs.  So for lws the effective portion of the
> build basically looks like:
> 
> 46 src_configure() {
> 47     local mycmakeargs=(
> 48         -DCMAKE_DISABLE_FIND_PACKAGE_Git=ON
> 49         -DLWS_HAVE_LIBCAP=$(usex caps)
> 50         -DLWS_IPV6=$(usex ipv6)
> 51         -DLWS_ROLE_DBUS=$(usex dbus)
> 52         -DLWS_WITHOUT_CLIENT=$(usex !client)
> 53         -DLWS_WITHOUT_TEST_CLIENT=$(usex !client)
> 54         -DLWS_WITH_ACCESS_LOG=$(usex access-log)
> 55         -DLWS_WITH_CGI=$(usex cgi)
> 56         -DLWS_WITH_GENERIC_SESSIONS=$(usex generic-sessions)
> 57         -DLWS_WITH_HTTP2=$(usex http2)
> 58         -DLWS_WITH_HTTP_PROXY=$(usex http-proxy)
> 59         -DLWS_WITH_HUBBUB=$(usex http-proxy)
> 60         -DLWS_WITH_LEJP=$(usex lejp)
> 61         -DLWS_WITH_LIBEV=$(usex libev)
> 62         -DLWS_WITH_LIBEVENT=$(usex libevent)
> 63         -DLWS_WITH_LIBUV=$(usex libuv)
> 64         -DLWS_WITH_PEER_LIMITS=$(usex peer-limits)
> 65         -DLWS_WITH_SERVER_STATUS=$(usex server-status)
> 66         -DLWS_WITH_SMTP=$(usex smtp)
> 67         -DLWS_WITH_SOCKS5=$(usex socks5)
> 68         -DLWS_WITH_SQLITE3=$(usex sqlite3)
> 69         -DLWS_WITH_SSL=$(usex ssl)
> 70         -DLWS_WITH_STATIC=$(usex static-libs)
> 71         -DLWS_WITH_THREADPOOL=$(usex threads)
> 72         -DLWS_WITH_ZIP_FOPS=$(usex zip)
> 73         -DLWS_WITHOUT_TESTAPPS=ON
> 74     )
> 75
> 76     cmake_src_configure
> 77}
> 
> The rest of it is just to control which combinations of those "USE"
> flags are legal.  And we've had some fights with that the last few weeks
> as we have a few users that needs to be able to strip lws down for
> minimal install footprint for embedded environments.  But it seems as we
> flip one flag others break.  Currently there's 23 individual USE flags,
> with some illegal combinations we've filtered out because it breaks the
> build.  The most obvious legality issues are around openssl vs libressl
> vs mbedtls ... and other restrictions like http-proxy requires client.
> Less obvious were smtp requires libuv.  Some of these we should probably

SMTP is in the middle of being rewritten atm.

> report (ideally along with patches) if it makes sense that they should
> function independently.

Sai is integrated into Gitohashi now so if you visit

https://libwebsockets.org/git/libwebsockets/tree/

... you can see the combinations of platforms and configurations that 
are in CI all in one place.  If you click on the icons, you can see the 
build logs and any package artifact (these are only produced for 
LWS_WITH_DISTRO_RECOMMENDED).

For non-Gentoo distros, they target a single build with the main 
features, it'd be great if they started using the provided 
LWS_WITH_DISTRO_RECOMMENDED because these enable building gitohashi and 
sai against that lws cleanly.

> Normally to bump it's a simple "ok, new version is available, update to
> new version tag" and move on.  However, there is still a fair amount of
> build-tests that I am to do, and that takes a significant amount of
> time.  Which is probably our biggest problem right now.  Ideally if we
> set options that require other options, but force those options off, if
> the configure can fail that would be ideal, but we'd still need to run
> through full builds for at least some combinations.
> 
> At 23 knobs that's over 8 million possible build combinations.  So it'll
> have to be a form of smoke test.  I'm thinking "-*", and then each
> individual flag on, so that's still about 20 or so builds to run
> through, but should show up the majority of on-off issues.

You can see from the link above we currently do 22 build option 
variation sets in our CI already over 8 platforms... these are a mixture 
of common cases like check with mbedtls and openssl and things that 
repeatedly broke before, like nonetwork.  If there are combinations that 
would be useful that are broken, I'm happy to hear about them.

BTW here's a github issue from just thisafternoon where the fix exists 
on -stable branch for many weeks but he picked up the last tag

https://github.com/warmcat/libwebsockets/issues/1909

... tagging everything isn't very pretty but it will save those guys 
time and my time to balance it.

-Andy

> Kind Regards,
> Jaco
> 


More information about the Libwebsockets mailing list