<rsbecker@xxxxxxxxxxxxx> writes:
> I have another patch almost ready for zlib and libcurl, but it is based on
> the OpenSSL change. Would you like a re-roll or should I wait for the merge?
> I do not have the PCRE - not available on my system, so someone else should
> do that one.
A two-patch series for zlib and libcURL that builds on top of
8b731b8d (version: --build-options reports OpenSSL version
information, 2024-06-19), which has already hit 'next', would be OK,
but most likely, these three are independent "for X in (cURL, zlib,
OpenSSL), append X if X is there", and when the three changes are
merged together, it would result in
#if defined CURL_something
strbuf_add*(...libcurl thing...);
#endif
#if defined OPENSSL_something
strbuf_add*(...openssl thing...);
#endif
#if defined libz_something
strbuf_add*(...zlib thing...);
#endif
with possible permutation of different ordering of them. And in
such a case, three parallel topics that build on the same base
(i.e. some recent tip of 'master') would be just fine, even though
they _surely_ will introduce trivial textual conflicts.
If you introduced a helper function or CPP macro to make it easy to
add the OpenSSL version string in your OpenSSL patch, and the other
two patches took advantage of the helper or CPP macro while adding
the zlib or libcURL version string, then it would be a different
story. A two-patch series for zlib and libcURL that builds on top
of the OpenSSL patch would become the best (and the only practical)
approach in such a case, but there is nothing in the OpenSSL patch
we have reviewed that these other two would want to depend on, so...
