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

Jaco Kroon jaco at uls.co.za
Wed May 6 19:57:48 CEST 2020


Bear with me please.

How many knobs do you have in total?

I'm thinking that a compile test for each and every combination isn't
required.  The more I think about this, the more I'm starting to think
there are only X number of options that would eliminate 99% of these
build issues.  Specifically:

1.  Everything off.  Probably not useful, but at least we know the base
stuff compiles.
2.  Turn every feature on individually, along with only the other
features that it requires (should require).
3.  For each of the "one of options, eg, openssl vs libressl vs mbedtls"
select one along with everything off.

This should flush out the far majority of build issues I reckon.  Plus
it'll effectively generate the list of inter-feature dependencies and
where appropriate you can then either take action to decouple them, or
document the dependency (so that it fails at config time rather than
build time).

Not critical for now, we'll proceed as per current.  We've discussed and
said we'll bump periodically or as and when needed.

Kind Regards,

On 2020/05/06 19:41, Andy Green wrote:

> 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=(
>> 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)
>> 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
> 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