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@xxxxxxxxx> writes: >> >>> "Randall S. Becker" <the.n.e.key@xxxxxxxxx> 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.
