From: Junio C Hamano <gitster@pobox•com>
To: <rsbecker@nexbridge•com>
Cc: "'Randall S. Becker'" <the.n.e.key@gmail•com>,
<git@vger•kernel.org>,
"'Randall S. Becker'" <randall.becker@nexbridge•ca>
Subject: Re: [PATCH v0 1/1] Teach git version --build-options about zlib+libcurl
Date: Fri, 21 Jun 2024 11:58:48 -0700 [thread overview]
Message-ID: <xmqqwmmijf6f.fsf@gitster.g> (raw)
In-Reply-To: <016501dac409$7dd5bc00$79813400$@nexbridge.com> (rsbecker@nexbridge.com's message of "Fri, 21 Jun 2024 14:33:14 -0400")
<rsbecker@nexbridge•com> writes:
> In this case, I was modelling the include after http.c, and remote-curl.c,
> which would have the same problem. I was going for consistency. Would not
> all three have to be fixed in a separate patch?
At least for build on platforms without libcURL, you build with
NO_CURL defined, i.e. "make NO_CURL=NoThanks", and anything that
includes <curl/curl.h> is *NOT* compiled at all, avoiding the broken
build. There is *NOTHING* that needs fixing in the existing code.
Only this patch under discussion is buggy that way.
>>FYI, in the merged result, I would prefer to order these entries
> semi-alphabetically,
>>e.g. perhaps stripping possible "lib" prefix or suffix and comparing the
> rest to result
>>in curl < openssl < z or something like that. Then we know where to add a
> new one,
>>whose name we do not know yet, in the future.
>
> I think that is logical. Do you need this redone? Although the OpenSSL
> inclusion is already merged from what I can see.
That is why the statement has "FYI". I'll do the merging.
Having them as two patches, one for libcurl and the other for zlib,
would be slightly cleaner. Otherwise my merge would have to become
"splitting the new one that adds libcurl+zlib into two hunks and let
the existing openssl one in between".
next prev parent reply other threads:[~2024-06-21 18:58 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-21 15:45 [PATCH v0 0/1] Teach git version --build-options about zlib+libcurl Randall S. Becker
2024-06-21 15:45 ` [PATCH v0 1/1] " Randall S. Becker
2024-06-21 18:20 ` Junio C Hamano
2024-06-21 18:28 ` Junio C Hamano
2024-06-21 18:33 ` rsbecker
2024-06-21 18:58 ` Junio C Hamano [this message]
2024-06-21 19:20 ` Junio C Hamano
2024-06-21 19:32 ` Randall Becker
2024-06-22 5:11 ` Junio C Hamano
2024-06-25 19:29 ` rsbecker
2024-06-25 20:58 ` Junio C Hamano
2024-06-25 22:02 ` rsbecker
2024-06-26 20:42 ` Jeff King
2024-06-26 22:28 ` Junio C Hamano
2024-06-26 20:46 ` Jeff King
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=xmqqwmmijf6f.fsf@gitster.g \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=randall.becker@nexbridge$(echo .)ca \
--cc=rsbecker@nexbridge$(echo .)com \
--cc=the.n.e.key@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox