Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > As noted in preceding commits checking against LIBCURL_VERSION_NUM > isn't as reliable as checking specific defines in curl, as some > distros have been known to backport features. Furthermore we had at > least one case of someone confusing base 10 for base 16 in comparing > the version. > > Let's add a git-curl-compat.h header that'll keep track of these > dependencies, and make the next round of deprecations easier. This > patch is mostly obvious, with the following exceptions: > > - In aeff8a61216 (http: implement public key pinning, 2016-02-15) a > dependency and warning() was added if curl older than 7.44.0 was > used, but the relevant code depended on CURLOPT_PINNEDPUBLICKEY, > introduced in 7.39.0. I'd feel safe with this change iff we positively know that the reason why the warning message and version guard back then said 7.44.0 instead of 7.39.0 was not because the symbol was there but the feature was broken between these two versions, and the feature became usable/reliable only after 7.44.0. I do not recall the review discussion around that commit offhand and somebody needs to dig the archive. > - We did not use CURL_SOCKOPT_OK and instead hardcoded its value in > a15d069a198 (http: enable keepalive on TCP sockets, 2013-10-12), > let's use it and guard its use by a new GITCURL_HAVE_* check. I agree with the spirit, but find the execution iffy. I may find it cleaner to hide all the version dependent details in curl-compat.h and to define CURL_SOCKOPT_OK to 0 there, iff the symbol is missing. That way, the use sites can unconditionally use CURL_SOCKOPT_OK, no? > - We guarded the support for http.version with a check for curl > 7.47.0, looking at the history of how that happen reveals that an > earlier on-list version of d73019feb44 (http: add support selecting > http version, 2018-11-08) depended on CURL_HTTP_VERSION_2TLS (which > was added in 7.47.0). > > But the version this code depended on was in fact 7.43.0, since > that's when CURL_HTTP_VERSION_2_0 was added. OK. > +#ifndef GIT_CURL_COMPAT_H > +#define GIT_CURL_COMPAT_H > + > +/** > + * This header centralized the declaration of our libcurl dependencies -lizes, not -lized, no? > + * to make it easy to discover the oldest versions we support, and to > + * inform decisions about removing support for older libcurl in the > + * future. > + * > + * The source of truth for what versions have which symbols is > + * https://github.com/curl/curl/blob/master/docs/libcurl/symbols-in-versions; > + * the release dates are taken from curl.git (at > + * https://github.com/curl/curl/). > + * > + * For each X symbol we need from curl we check if it exists and > + * declare our own GIT_CURl_HAVE_X, or if it's for both X and Y > + * GIT_CURl_HAVE_X_and_Y, where the "Y" in "X_and_Y" is only the part GIT_CURL, not GIT_CURl, no? > + * of the symbol name that "X" and "Y" don't have in common. > + * > + * We avoid comparisons against LIBCURL_VERSION_NUM, enterprise > + * distros have been known to backport symbols to their older curl > + * versions. > + * > + * Keep any symbols in date order of when their support was > + * introduced, oldest first. The above two paragraphs are somewhat at odds. Perhaps with "..., oldest first, in the official version of cURL library", it becomes a non-issue, though. The approach may mostly be sensible, but as I said, it is overkill for things like this one: [in curl-compat.h] > +/** > + * CURL_SOCKOPT_OK was added in 7.21.5, released in April 2011. > + */ > +#ifdef CURL_SOCKOPT_OK > +#define GITCURL_HAVE_CURL_SOCKOPT_OK 1 > +#endif [in code] > if (rc < 0) > warning_errno("unable to set SO_KEEPALIVE on socket"); > > - return 0; /* CURL_SOCKOPT_OK only exists since curl 7.21.5 */ > +#ifdef GITCURL_HAVE_CURL_SOCKOPT_OK > + return CURL_SOCKOPT_OK; > +#else > + return 0; > +#endif > } It would be far simpler and cleaner to do this instead only in curl-compat.h, no? #ifndef CURL_SOCKOPT_OK #define CURL_SOCKOPT_OK 0 #endif When we drop support for versions that do not have symbol X, the header must change (you'd probably remove the entry with the comment for the symbol X), but there is no need to touch all the code that uses GITCURL_HAVE_X for a symbol like this one. Again, of course, not all symbols and the way we conditionally compile things are like this simple, and GITCURL_HAVE_* approach may have merit at those places, but definitely not here. I really wish that you did not succumb to the temptation of feature creep while going from v2 to v3. With this close to the preview release, what we want is not a topic that covers more, but a topic that corrects issues that have been identified in it and can be merged down for the next release before -rc1. Thanks.
