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

From

rsbecker@nexbridge.com <rsbecker@nexbridge.com>

Date

Jun 21, 2024, 01:50 UTC

Message-ID

<010201dac37d$68a96070$39fc2150$@nexbridge.com>

In-Reply-To

<xmqqv823p3tz.fsf@gitster.g>

On Thursday, June 20, 2024 7:55 PM, Junio C Hamano wrote:

><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...