{"thread":{"id":"61667","subject":"[PATCH v0 0/1] Teach git version --build-options about zlib+libcurl","startedAt":"2024-06-21T15:46:27Z","lastAt":"2024-06-26T22:28:52Z","messageCount":15,"participants":["Randall S. Becker","Junio C Hamano","rsbecker@nexbridge.com","Randall Becker","Jeff King"],"isPatch":true,"patchVersion":0,"patchTotal":1},"messages":[{"id":"497497","messageId":"20240621154552.62038-1-randall.becker@nexbridge.ca","threadId":"61667","inReplyTo":null,"subject":"[PATCH v0 0/1] Teach git version --build-options about zlib+libcurl","fromName":"Randall S. Becker","fromEmail":"the.n.e.key@gmail.com","sentAt":"2024-06-21T15:45:51Z","receivedAt":"2024-06-21T15:46:27Z","isPatch":true,"sender":{"key":"the.n.e.key@gmail.com","avatar":null},"body":"This simple series adds the zlib and libcurl versions, if any, used during a git\nbuild.\n\nAs an example, the following is appended to the git version --build-options\nreport:\n\n libcurl: 8.7.1\n\tzlib: 1.3.1\n\nRandall S. Becker (1):\n Teach git version --build-options to know about zlib and libcurl\n versions.\n\n help.c | 7 +++++++\n 1 file changed, 7 insertions(+)\n\n-- \n2.43.0\n\n"},{"id":"497498","messageId":"20240621154552.62038-2-randall.becker@nexbridge.ca","threadId":"61667","inReplyTo":"20240621154552.62038-1-randall.becker@nexbridge.ca","subject":"[PATCH v0 1/1] Teach git version --build-options about zlib+libcurl","fromName":"Randall S. Becker","fromEmail":"the.n.e.key@gmail.com","sentAt":"2024-06-21T15:45:52Z","receivedAt":"2024-06-21T15:46:28Z","isPatch":true,"sender":{"key":"the.n.e.key@gmail.com","avatar":null},"body":"This change uses the zlib supplied ZLIB_VERSION #define supplied text\nmacro and the libcurl LIBCURL_VERSION #define text macro. No\nstringification is required for either variable's use. If either of\nthe #define is not present, that version is not reported.\n\nSigned-off-by: Randall S. Becker \n---\n help.c | 7 +++++++\n 1 file changed, 7 insertions(+)\n\ndiff --git a/help.c b/help.c\nindex 1d057aa607..f378750af4 100644\n--- a/help.c\n+++ b/help.c\n@@ -1,4 +1,5 @@\n #include \"git-compat-util.h\"\n+#include \"git-curl-compat.h\"\n #include \"config.h\"\n #include \"builtin.h\"\n #include \"exec-cmd.h\"\n@@ -757,6 +758,12 @@ void get_version_info(struct strbuf *buf, int show_build_options)\n \n \t\tif (fsmonitor_ipc__is_supported())\n \t\t\tstrbuf_addstr(buf, \"feature: fsmonitor--daemon\\n\");\n+#if defined LIBCURL_VERSION\n+\t\tstrbuf_addf(buf, \"libcurl: %s\\n\", LIBCURL_VERSION);\n+#endif\n+#if defined ZLIB_VERSION\n+\t\tstrbuf_addf(buf, \"zlib: %s\\n\", ZLIB_VERSION);\n+#endif\n \t}\n }\n \n-- \n2.43.0\n\n"},{"id":"497512","messageId":"xmqqmsnekvir.fsf@gitster.g","threadId":"61667","inReplyTo":"20240621154552.62038-2-randall.becker@nexbridge.ca","subject":"Re: [PATCH v0 1/1] Teach git version --build-options about zlib+libcurl","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-06-21T18:20:28Z","receivedAt":"2024-06-21T18:20:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Randall S. Becker\" writes:\n\n> This change uses the zlib supplied ZLIB_VERSION #define supplied text\n> macro and the libcurl LIBCURL_VERSION #define text macro. No\n> stringification is required for either variable's use. If either of\n> the #define is not present, that version is not reported.\n\n\"the zlib supplied ZLIB_VERSION #define supplied text macro\" is\nquite a mouthful. Something like\n\n version: --build-options reports zlib and libcurl version information\n\n Use ZLIB_VERSION and LIBCURL_VERSION to show them, if defined, in\n \"git version --build-options\" output.\n\nshould be sufficient.\n\nWe will assume that \n\n (1) LIBFROTZ_VERSION, if defined, will always be of the same type\n (luckily, all three we are dealing with use a C-string so\n \"strbuf_addf(buf, \"%s\", LIBFROTZ_VERSION)\" is good), and that\n\n (2) no random origin other than the frotz project will define the\n CPP macro LIBFROTZ_VERSION to confuse us.\n\nBoth are sensible assumptions that would allow us to trust a\nhardcoded strbuf_addf() invocation per each library is sufficient If\na library uses LIBFROTZ_MAJOR and LIBFROTZ_MINOR we may have to do\n\"strbuf_addf(buf, \"%s.%s\" LIBFROTZ_MAJOR, LIBFROTZ_MINOR)\" that is\ndifferent from others, but the point is the version identification\nscheme would be constant across different versions of the same\nlibrary.\n\nThe actual code to report versions should be trivial, once we get\nthe mechanism to make necessary CPP macros available (when present)\nright, but the latter needs a bit more work than this patch shows.\n\nHere is the first change your patch does:\n\n> #include \"git-compat-util.h\"\n> +#include \"git-curl-compat.h\"\n\nThe file begins like so:\n\n #ifndef GIT_CURL_COMPAT_H\n #define GIT_CURL_COMPAT_H\n #include \n\t...\n\nIf you do not have any anywhere on your system,\nI suspect this will break the build, instead of silently leaving\nLIBCURL_VERSION undefined.\n\n> #include \"config.h\"\n> #include \"builtin.h\"\n> #include \"exec-cmd.h\"\n> @@ -757,6 +758,12 @@ void get_version_info(struct strbuf *buf, int show_build_options)\n> \n> \t\tif (fsmonitor_ipc__is_supported())\n> \t\t\tstrbuf_addstr(buf, \"feature: fsmonitor--daemon\\n\");\n> +#if defined LIBCURL_VERSION\n> +\t\tstrbuf_addf(buf, \"libcurl: %s\\n\", LIBCURL_VERSION);\n> +#endif\n> +#if defined ZLIB_VERSION\n> +\t\tstrbuf_addf(buf, \"zlib: %s\\n\", ZLIB_VERSION);\n> +#endif\n\nFYI, in the merged result, I would prefer to order these entries\nsemi-alphabetically, e.g. perhaps stripping possible \"lib\" prefix or\nsuffix and comparing the rest to result in curl < openssl < z or\nsomething like that. Then we know where to add a new one, whose\nname we do not know yet, in the future.\n\nThanks.\n"},{"id":"497513","messageId":"xmqqiky2kv55.fsf@gitster.g","threadId":"61667","inReplyTo":"xmqqmsnekvir.fsf@gitster.g","subject":"Re: [PATCH v0 1/1] Teach git version --build-options about zlib+libcurl","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-06-21T18:28:38Z","receivedAt":"2024-06-21T18:28:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> \"the zlib supplied ZLIB_VERSION #define supplied text macro\" is\n> quite a mouthful. Something like\n>\n> version: --build-options reports zlib and libcurl version information\n>\n> Use ZLIB_VERSION and LIBCURL_VERSION to show them, if defined, in\n> \"git version --build-options\" output.\n>\n> should be sufficient.\n\nNah, that is still more verbose than necessary. Just saying\n\n\tShow ZLIB_VERSION and LIBCURL_VERSION, if defined, in ...\n\nis sufficient.\n"},{"id":"497514","messageId":"016501dac409$7dd5bc00$79813400$@nexbridge.com","threadId":"61667","inReplyTo":"xmqqmsnekvir.fsf@gitster.g","subject":"RE: [PATCH v0 1/1] Teach git version --build-options about zlib+libcurl","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-06-21T18:33:14Z","receivedAt":"2024-06-21T18:33:27Z","isPatch":true,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Friday, June 21, 2024 2:20 PM, Junio C Hamano wrote:\n>\"Randall S. Becker\" writes:\n>\n>> This change uses the zlib supplied ZLIB_VERSION #define supplied text\n>> macro and the libcurl LIBCURL_VERSION #define text macro. No\n>> stringification is required for either variable's use. If either of\n>> the #define is not present, that version is not reported.\n>\n>\"the zlib supplied ZLIB_VERSION #define supplied text macro\" is quite a\nmouthful.\n>Something like\n>\n> version: --build-options reports zlib and libcurl version information\n>\n> Use ZLIB_VERSION and LIBCURL_VERSION to show them, if defined, in\n> \"git version --build-options\" output.\n>\n>should be sufficient.\n\nDo you want me to reissue the merge? This looks fine to me.\n\n>We will assume that\n>\n> (1) LIBFROTZ_VERSION, if defined, will always be of the same type\n> (luckily, all three we are dealing with use a C-string so\n> \"strbuf_addf(buf, \"%s\", LIBFROTZ_VERSION)\" is good), and that\n>\n> (2) no random origin other than the frotz project will define the\n> CPP macro LIBFROTZ_VERSION to confuse us.\n>\n>Both are sensible assumptions that would allow us to trust a hardcoded\n>strbuf_addf() invocation per each library is sufficient If a library uses\n>LIBFROTZ_MAJOR and LIBFROTZ_MINOR we may have to do \"strbuf_addf(buf,\n>\"%s.%s\" LIBFROTZ_MAJOR, LIBFROTZ_MINOR)\" that is different from others, but\n>the point is the version identification scheme would be constant across\ndifferent\n>versions of the same library.\n>\n>The actual code to report versions should be trivial, once we get the\nmechanism to\n>make necessary CPP macros available (when present) right, but the latter\nneeds a\n>bit more work than this patch shows.\n>\n>Here is the first change your patch does:\n>\n>> #include \"git-compat-util.h\"\n>> +#include \"git-curl-compat.h\"\n>\n>The file begins like so:\n>\n> #ifndef GIT_CURL_COMPAT_H\n> #define GIT_CURL_COMPAT_H\n> #include \n>\t...\n>\n\nIn this case, I was modelling the include after http.c, and remote-curl.c,\nwhich would have the same problem. I was going for consistency. Would not\nall three have to be fixed in a separate patch?\n\n>If you do not have any anywhere on your system, I suspect\nthis will\n>break the build, instead of silently leaving LIBCURL_VERSION undefined.\n>\n>> #include \"config.h\"\n>> #include \"builtin.h\"\n>> #include \"exec-cmd.h\"\n>> @@ -757,6 +758,12 @@ void get_version_info(struct strbuf *buf, int\n>> show_build_options)\n>>\n>> \t\tif (fsmonitor_ipc__is_supported())\n>> \t\t\tstrbuf_addstr(buf, \"feature: fsmonitor--daemon\\n\");\n>> +#if defined LIBCURL_VERSION\n>> +\t\tstrbuf_addf(buf, \"libcurl: %s\\n\", LIBCURL_VERSION); #endif\n#if\n>> +defined ZLIB_VERSION\n>> +\t\tstrbuf_addf(buf, \"zlib: %s\\n\", ZLIB_VERSION); #endif\n>\n>FYI, in the merged result, I would prefer to order these entries\nsemi-alphabetically,\n>e.g. perhaps stripping possible \"lib\" prefix or suffix and comparing the\nrest to result\n>in curl < openssl < z or something like that. Then we know where to add a\nnew one,\n>whose name we do not know yet, in the future.\n\nI think that is logical. Do you need this redone? Although the OpenSSL\ninclusion is already merged from what I can see.\n\n>Thanks.\n\n"},{"id":"497517","messageId":"xmqqwmmijf6f.fsf@gitster.g","threadId":"61667","inReplyTo":"016501dac409$7dd5bc00$79813400$@nexbridge.com","subject":"Re: [PATCH v0 1/1] Teach git version --build-options about zlib+libcurl","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-06-21T18:58:48Z","receivedAt":"2024-06-21T18:58:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":" writes:\n\n> In this case, I was modelling the include after http.c, and remote-curl.c,\n> which would have the same problem. I was going for consistency. Would not\n> all three have to be fixed in a separate patch?\n\nAt least for build on platforms without libcURL, you build with\nNO_CURL defined, i.e. \"make NO_CURL=NoThanks\", and anything that\nincludes is *NOT* compiled at all, avoiding the broken\nbuild. There is *NOTHING* that needs fixing in the existing code.\nOnly this patch under discussion is buggy that way.\n\n>>FYI, in the merged result, I would prefer to order these entries\n> semi-alphabetically,\n>>e.g. perhaps stripping possible \"lib\" prefix or suffix and comparing the\n> rest to result\n>>in curl < openssl < z or something like that. Then we know where to add a\n> new one,\n>>whose name we do not know yet, in the future.\n>\n> I think that is logical. Do you need this redone? Although the OpenSSL\n> inclusion is already merged from what I can see.\n\nThat is why the statement has \"FYI\". I'll do the merging. \n\nHaving them as two patches, one for libcurl and the other for zlib,\nwould be slightly cleaner. Otherwise my merge would have to become\n\"splitting the new one that adds libcurl+zlib into two hunks and let\nthe existing openssl one in between\".\n"},{"id":"497518","messageId":"xmqqplsaje6z.fsf@gitster.g","threadId":"61667","inReplyTo":"xmqqwmmijf6f.fsf@gitster.g","subject":"Re: [PATCH v0 1/1] Teach git version --build-options about zlib+libcurl","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-06-21T19:20:04Z","receivedAt":"2024-06-21T19:20:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> At least for build on platforms without libcURL, you build with\n> NO_CURL defined, i.e. \"make NO_CURL=NoThanks\", and anything that\n> includes is *NOT* compiled at all, avoiding the broken\n> build.\n\nUnfortunately, we cannot use the same trick, i.e. \"Makefile\nknows not to even compile when NO_CURL is set\", as this change is to\nhelp.c and we cannot say \"if you do not have libcURL, you do not get\nany help\" ;-)\n\n #ifndef NO_CURL\n #include \"git-curl-compat.h\"\n #endif\n\nmay be a simplest workaround, as Makefile does this:\n\n ifdef NO_CURL\n BASIC_CFLAGS += -DNO_CURL\n\t\t...\n\n"},{"id":"497519","messageId":"DS0PR17MB60315038F42A05C84A56302EF4C92@DS0PR17MB6031.namprd17.prod.outlook.com","threadId":"61667","inReplyTo":"xmqqplsaje6z.fsf@gitster.g","subject":"RE: [PATCH v0 1/1] Teach git version --build-options about zlib+libcurl","fromName":"Randall Becker","fromEmail":"randall.becker@nexbridge.ca","sentAt":"2024-06-21T19:32:03Z","receivedAt":"2024-06-21T19:32:07Z","isPatch":true,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Friday, June 21, 2024 3:20 PM, Junio C Hamano wrote:\n>To: rsbecker@nexbridge.com\n>Cc: 'Randall S. Becker' ; git@vger.kernel.org; Randall\n>Becker \n>Subject: Re: [PATCH v0 1/1] Teach git version --build-options about zlib+libcurl\n>\n>Junio C Hamano writes:\n>\n>> At least for build on platforms without libcURL, you build with\n>> NO_CURL defined, i.e. \"make NO_CURL=NoThanks\", and anything that\n>> includes is *NOT* compiled at all, avoiding the broken\n>> build.\n>\n>Unfortunately, we cannot use the same trick, i.e. \"Makefile knows not to even\n>compile when NO_CURL is set\", as this change is to help.c and we cannot say \"if you\n>do not have libcURL, you do not get any help\" ;-)\n>\n> #ifndef NO_CURL\n> #include \"git-curl-compat.h\"\n> #endif\n>\n>may be a simplest workaround, as Makefile does this:\n>\n> ifdef NO_CURL\n> BASIC_CFLAGS += -DNO_CURL\n>\t\t...\n\nThat makes sense\n\n"},{"id":"497536","messageId":"xmqqtthlimtr.fsf@gitster.g","threadId":"61667","inReplyTo":"xmqqplsaje6z.fsf@gitster.g","subject":"Re: [PATCH v0 1/1] Teach git version --build-options about zlib+libcurl","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-06-22T05:11:12Z","receivedAt":"2024-06-22T05:11:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Unfortunately, we cannot use the same trick, i.e. \"Makefile\n> knows not to even compile when NO_CURL is set\", as this change is to\n> help.c and we cannot say \"if you do not have libcURL, you do not get\n> any help\" ;-)\n>\n> #ifndef NO_CURL\n> #include \"git-curl-compat.h\"\n> #endif\n>\n> may be a simplest workaround, as Makefile does this:\n>\n> ifdef NO_CURL\n> BASIC_CFLAGS += -DNO_CURL\n> \t\t...\n\nSo, the version I queued looks like so:\n\n diff --git a/help.c b/help.c\n index ce55aaa2c0..92bfef140b 100644\n --- a/help.c\n +++ b/help.c\n @@ -15,6 +15,10 @@\n #include \"prompt.h\"\n #include \"fsmonitor-ipc.h\"\n\n +#ifndef NO_CURL\n +#include \"git-curl-compat.h\" /* For LIBCURL_VERSION only */\n +#endif\n +\n struct category_description {\n uint32_t category;\n const char *desc;\n @@ -757,6 +761,9 @@ void get_version_info(struct strbuf ...\n\n if (fsmonitor_ipc__is_supported())\n strbuf_addstr(buf, \"feature: fsmonitor--daemon\\n\");\n +#if defined LIBCURL_VERSION\n +\t\tstrbuf_addf(buf, \"libcurl: %s\\n\", LIBCURL_VERSION);\n +#endif\n #if defined OPENSSL_VERSION_TEXT\n strbuf_addf(buf, \"OpenSSL: %s\\n\", OPENSSL_VERSION_TEXT);\n #endif\n\nbut then there are a few \"side builds\" at GitHub CI, one of which is\n\"minimum fuzzer\" build. It compiles bunch of object files without\ngiving much build options but the final target of the build is not\n\"git\" but something else [*]. And because the job is not interesting\nin building a working \"git\", the environment does not install libcURL,\nleading to a failed build.\n\nI sent a separate patch to address this build failure, which is\nfound at https://lore.kernel.org/git/xmqqwmmhimxx.fsf@gitster.g/\n\n\n\n[Reference]\n * https://github.com/git/git/actions/runs/9623017127/job/26544995557\n"},{"id":"497657","messageId":"03ef01dac735$f3496ac0$d9dc4040$@nexbridge.com","threadId":"61667","inReplyTo":"xmqqtthlimtr.fsf@gitster.g","subject":"RE: [PATCH v0 1/1] Teach git version --build-options about zlib+libcurl","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-06-25T19:29:03Z","receivedAt":"2024-06-25T19:29:12Z","isPatch":true,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Saturday, June 22, 2024 1:11 AM, Junio C Hamano wrote:\n>Junio C Hamano writes:\n>\n>> Unfortunately, we cannot use the same trick, i.e. \"Makefile knows not\n>> to even compile when NO_CURL is set\", as this change is to help.c and\n>> we cannot say \"if you do not have libcURL, you do not get any help\"\n>> ;-)\n>>\n>> #ifndef NO_CURL\n>> #include \"git-curl-compat.h\"\n>> #endif\n>>\n>> may be a simplest workaround, as Makefile does this:\n>>\n>> ifdef NO_CURL\n>> BASIC_CFLAGS += -DNO_CURL\n>> \t\t...\n>\n>So, the version I queued looks like so:\n>\n> diff --git a/help.c b/help.c\n> index ce55aaa2c0..92bfef140b 100644\n> --- a/help.c\n> +++ b/help.c\n> @@ -15,6 +15,10 @@\n> #include \"prompt.h\"\n> #include \"fsmonitor-ipc.h\"\n>\n> +#ifndef NO_CURL\n> +#include \"git-curl-compat.h\" /* For LIBCURL_VERSION only */\n> +#endif\n> +\n> struct category_description {\n> uint32_t category;\n> const char *desc;\n> @@ -757,6 +761,9 @@ void get_version_info(struct strbuf ...\n>\n> if (fsmonitor_ipc__is_supported())\n> strbuf_addstr(buf, \"feature:\nfsmonitor--daemon\\n\");\n> +#if defined LIBCURL_VERSION\n> +\t\tstrbuf_addf(buf, \"libcurl: %s\\n\", LIBCURL_VERSION);\n> +#endif\n> #if defined OPENSSL_VERSION_TEXT\n> strbuf_addf(buf, \"OpenSSL: %s\\n\",\nOPENSSL_VERSION_TEXT);\n> #endif\n>\n>but then there are a few \"side builds\" at GitHub CI, one of which is\n\"minimum\n>fuzzer\" build. It compiles bunch of object files without giving much build\noptions\n>but the final target of the build is not \"git\" but something else [*]. And\nbecause the\n>job is not interesting in building a working \"git\", the environment does\nnot install\n>libcURL, leading to a failed build.\n>\n>I sent a separate patch to address this build failure, which is found at\n>https://lore.kernel.org/git/xmqqwmmhimxx.fsf@gitster.g/\n\nMy take on the separate patches and discussion about reporting run-time\nvalues of libcurl, zlib, and OpenSSL, is that these are being added to\n--build-options not --runtime-options (does not exist yet). I think that\ngrabbing run-time values could be confusing to users who expect the\n--build-options even if comparing the two values.\n--Randall\n\n"},{"id":"497658","messageId":"xmqqmsn87n9x.fsf@gitster.g","threadId":"61667","inReplyTo":"03ef01dac735$f3496ac0$d9dc4040$@nexbridge.com","subject":"Re: [PATCH v0 1/1] Teach git version --build-options about zlib+libcurl","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-06-25T20:58:18Z","receivedAt":"2024-06-25T20:58:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":" writes:\n\n> My take on the separate patches and discussion about reporting run-time\n> values of libcurl, zlib, and OpenSSL, is that these are being added to\n> --build-options not --runtime-options (does not exist yet). I think that\n> grabbing run-time values could be confusing to users who expect the\n> --build-options even if comparing the two values.\n\nYup. I thought that the consensus was to leave all those extra\ncomplexities like runtime versions for a later and separate topic\ndone after the dust from this change settles.\n\nThanks.\n"},{"id":"497659","messageId":"03f901dac74b$740c78e0$5c256aa0$@nexbridge.com","threadId":"61667","inReplyTo":"xmqqmsn87n9x.fsf@gitster.g","subject":"RE: [PATCH v0 1/1] Teach git version --build-options about zlib+libcurl","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-06-25T22:02:58Z","receivedAt":"2024-06-25T22:03:15Z","isPatch":true,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Tuesday, June 25, 2024 4:58 PM, Junio C Hamano wrote:\n> writes:\n>\n>> My take on the separate patches and discussion about reporting\n>> run-time values of libcurl, zlib, and OpenSSL, is that these are being\n>> added to --build-options not --runtime-options (does not exist yet). I\n>> think that grabbing run-time values could be confusing to users who\n>> expect the --build-options even if comparing the two values.\n>\n>Yup. I thought that the consensus was to leave all those extra\ncomplexities like\n>runtime versions for a later and separate topic done after the dust from\nthis change\n>settles.\n\nSo did I, but there was other chatter that made me think we did not.\n\n"},{"id":"497729","messageId":"20240626204232.GD441931@coredump.intra.peff.net","threadId":"61667","inReplyTo":"xmqqmsn87n9x.fsf@gitster.g","subject":"Re: [PATCH v0 1/1] Teach git version --build-options about zlib+libcurl","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-06-26T20:42:32Z","receivedAt":"2024-06-26T20:42:35Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jun 25, 2024 at 01:58:18PM -0700, Junio C Hamano wrote:\n\n> writes:\n> \n> > My take on the separate patches and discussion about reporting run-time\n> > values of libcurl, zlib, and OpenSSL, is that these are being added to\n> > --build-options not --runtime-options (does not exist yet). I think that\n> > grabbing run-time values could be confusing to users who expect the\n> > --build-options even if comparing the two values.\n> \n> Yup. I thought that the consensus was to leave all those extra\n> complexities like runtime versions for a later and separate topic\n> done after the dust from this change settles.\n\nMy only qualm is that reading curl.h at all in a program that is not\ngoing to link it feels a bit funny (it is declaring symbols that will\nnot be available at link time). And we could fix that immediately by\nhaving \"remote-https --build-options\".\n\nAdding a curl_version() check on top of that could come later, but of\ncourse it would be easy to do.\n\nBut that may just be me being overly conservative. If nobody looks at\nthose symbols, I'm not sure what harm would come.\n\n-Peff\n"},{"id":"497730","messageId":"20240626204613.GE441931@coredump.intra.peff.net","threadId":"61667","inReplyTo":"03ef01dac735$f3496ac0$d9dc4040$@nexbridge.com","subject":"Re: [PATCH v0 1/1] Teach git version --build-options about zlib+libcurl","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-06-26T20:46:13Z","receivedAt":"2024-06-26T20:46:16Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jun 25, 2024 at 03:29:03PM -0400, rsbecker@nexbridge.com wrote:\n\n> My take on the separate patches and discussion about reporting run-time\n> values of libcurl, zlib, and OpenSSL, is that these are being added to\n> --build-options not --runtime-options (does not exist yet). I think that\n> grabbing run-time values could be confusing to users who expect the\n> --build-options even if comparing the two values.\n\nI think that's a valid concern. I assumed we'd show both runtime and\nbuild-time values side by side, clearly labeled, rather than replace one\nwith the other. I don't see much need for --runtime-options. The point\nof --build-options is to gather info about the binary for debugging.\nWhile technically you can swap out the dynamic library whenever you\nlike, in practice I think it is about asking \"what will happen now when\nI run git\".\n\nLikewise, you could answer that part with \"ldd git\", but this is about\nmaking it simpler to gather the information in one place.\n\n-Peff\n"},{"id":"497738","messageId":"xmqqbk3nwd7l.fsf@gitster.g","threadId":"61667","inReplyTo":"20240626204232.GD441931@coredump.intra.peff.net","subject":"Re: [PATCH v0 1/1] Teach git version --build-options about zlib+libcurl","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-06-26T22:28:46Z","receivedAt":"2024-06-26T22:28:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> But that may just be me being overly conservative. If nobody looks at\n> those symbols, I'm not sure what harm would come.\n\nYeah, perhaps on some exotic systems it may cause problems, but\nuntil we see such a system, or we want to extend it to do the\ncurl_version() call for runtime, whichever comes earlier, I think\nwe can leave it as a (#leftoverbits) \"future enhancement and\nclean-up\" task to be done after the dust settles.\n\nThanks.\n"}]}