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 18:37:31 -0400 [thread overview]
Message-ID: <00ea01dac362$73935e20$5aba1a60$@nexbridge.com> (raw)
In-Reply-To: <DS0PR17MB60311D246BF2E89FAEB3C64DF4C82@DS0PR17MB6031.namprd17.prod.outlook.com>
On Thursday, June 20, 2024 2:48 PM, Randall Becker wrote:
>On Thursday, June 20, 2024 2:35 PM, Junio C Hamano wrote:
>>Junio C Hamano <gitster@pobox.com> writes:
>>
>>> "Randall S. Becker" <the.n.e.key@gmail.com> writes:
>>>
>>>> This change uses the OpenSSL supplied OPENSSL_VERSION_TEXT #define
>>>> supplied for this purpose by that project. If the #define is not
>>>> present, the version is not reported.
>>> ...
>>> If some unknown version of OpenSSL does define it but not as a string
>>> constant, it would break the build, e.g.,
>>>
>>> #define OPENSSL_VERSION_TEXT 2 plus 4 is 6
>>>
>>> We could stringify it ourselves, but that is probably not worth
>>> worrying about.
>>>
>>> Will queue. Thanks.
>>
>>Having said that, we do link with and depend on libraries like libcURL,
>>libPCRE, libz, etc. I wonder if they are also worth reporting, and if so
how?
>>
>>We can leave it just like any other new features, "if you have an itch
>>to see it, you can offer a patch", but I am wondering if we are going
>>to get a several more, we'd at least want to standardize the process
>>and the output (e.g., do we limit the line counts to 1 and line length to
some
>reasonably low number?).
>
>I was thinking about those also, but this was a minimalist implementation
>(opensslv.h comes in via git-compat-util.h - so I did not need to bring
anything else
>into the code). If anyone is interested, the libcurl version is in
curlver.h
>(LIBCURL_VERSION) - but I think it is more important to have the OpenSSL
version
>as this is an important compatibility indicator. zlib.h has ZLIB_VERSION
(text form). I
>don't have libPCRE, so can't tell. I can do another series for the others,
but those
>would impact help.c includes, unlike this one.
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.
next prev parent reply other threads:[~2024-06-20 22:37 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 [this message]
2024-06-20 23:55 ` Junio C Hamano
2024-06-21 1:50 ` rsbecker
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='00ea01dac362$73935e20$5aba1a60$@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.