From: <rsbecker@nexbridge.com>
To: "'Junio C Hamano'" <gitster@pobox.com>
Cc: <git@vger.kernel.org>
Subject: RE: [PATCH v0 1/1] Teach git version --build-options about OpenSSL
Date: Thu, 20 Jun 2024 21:50:29 -0400 [thread overview]
Message-ID: <010201dac37d$68a96070$39fc2150$@nexbridge.com> (raw)
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...
I think I would rather let each one stand. Embedding an #if defined inside a
macro makes me nervous, considering it is compiler version dependent. Would
putting each one in its own commit work for you?
--Randall
next prev parent reply other threads:[~2024-06-21 1:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-19 17:24 [PATCH v0 0/1] Teach git version --build-options about OpenSSL Randall S. Becker
2024-06-19 17:24 ` [PATCH v0 1/1] " Randall S. Becker
2024-06-20 18:27 ` Junio C Hamano
2024-06-20 18:35 ` Junio C Hamano
2024-06-20 18:48 ` Randall Becker
2024-06-20 22:37 ` rsbecker
2024-06-20 23:55 ` Junio C Hamano
2024-06-21 1:50 ` rsbecker [this message]
2024-06-21 16:18 ` Junio C Hamano
2024-06-20 18:36 ` Randall Becker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='010201dac37d$68a96070$39fc2150$@nexbridge.com' \
--to=rsbecker@nexbridge.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.