Re: [PATCH 4/4] imap-send: use curl by default

From: Martin Ågren <martin.agren@gmail.com>
Date: Aug 7, 2017, 17:37 UTC
Message-ID: <CAN0heSpSXRNgGeJ7TKOwPZJ3Puc1EvVUv1u84ghwDHhtE7=VHQ@mail.gmail.com>
In-Reply-To: <890d4028-1351-a7b9-1797-cf419d5f01e8@morey-chaisemartin.com>

On 7 August 2017 at 19:10, Nicolas Morey-Chaisemartin <nicolas@morey-chaisemartin.com> wrote:

Show 39 quoted lines

>
>
> Le 07/08/2017 à 18:37, Martin Ågren a écrit :
>> On 7 August 2017 at 16:04, Nicolas Morey-Chaisemartin
>> <nicolas@morey-chaisemartin.com> wrote:
>>> Signed-off-by: Nicolas Morey-Chaisemartin <nicolas@morey-chaisemartin.com>
>>> ---
>>>  imap-send.c | 6 ------
>>>  1 file changed, 6 deletions(-)
>>>
>>> diff --git a/imap-send.c b/imap-send.c
>>> index 90b8683ed..4ebc16437 100644
>>> --- a/imap-send.c
>>> +++ b/imap-send.c
>>> @@ -35,13 +35,7 @@ typedef void *SSL;
>>>  #include "http.h"
>>>  #endif
>>>
>>> -#if defined(USE_CURL_FOR_IMAP_SEND) && defined(NO_OPENSSL)
>>> -/* only available option */
>>>  #define USE_CURL_DEFAULT 1
>>> -#else
>>> -/* strictly opt in */
>>> -#define USE_CURL_DEFAULT 0
>>> -#endif
>>>
>>>  static int verbosity;
>>>  static int use_curl = USE_CURL_DEFAULT;
>> So this is now basically "static int use_curl = 1;".
>>
>> Do we need a compile-time escape-hatch in case someone really needs
>> to avoid curl, e.g., because they have a too old version? I suppose
>> there is a conceptual difference between the "default", i.e., the value
>> of USE_CURL_DEFAULT that is assigned to "use_curl", and the "default
>> default", i.e., the value that is normally assigned to USE_CURL_DEFAULT.
>>
>> Martin
>
> The curl code depends on USE_CURL_FOR_IMAP_SEND so even with use_curl == 1, it won't be an issue for people without curl (or old one).

I have just looked at the sources and haven't thought too hard about it, but doesn't it mean that compiling without USE_CURL_FOR_IMAP_SEND results in a binary such that you must use --no-curl or get used to seeing "warning: --curl not supported in this build"?

> I wasn't sure whether to drop the define or not and figure it might be worth keeping in case in change in the future for some reason.
> I don't mind dropping it and hardcofing the default to 1

I did not intend to suggest that. Just to be clear, I am very unfamiliar with most of the Git codebase. Please don't take anything I say as advice. :) As a question about something you have or haven't already thought about, sure. :)

Martin