Re: [PATCH v0 1/1] Teach git version --build-options about OpenSSL

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 20, 2024, 23:55 UTC
Message-ID: <xmqqv823p3tz.fsf@gitster.g>
In-Reply-To: <00ea01dac362$73935e20$5aba1a60$@nexbridge.com>

<rsbecker@nexbridge.com> 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...