On Sat, Jan 14, 2023 at 08:15:21AM -0800, Junio C Hamano wrote: > Yeah, I like that approach. > > But not this one ... > > > + CURL_IGNORE_DEPRECATION( > > + curl_easy_setopt(result, CURLOPT_REDIR_PROTOCOLS, > > + get_curl_allowed_protocols(0)); > > + curl_easy_setopt(result, CURLOPT_PROTOCOLS, > > + get_curl_allowed_protocols(-1)); > > + ) > > > > though I think that was introduced only in 7.87.0 along with the > > deprecation warnings themselves, so we'd need to have a fallback like: > > > > #ifndef CURL_IGNORE_DEPRECATION(x) > > #define CURL_IGNORE_DEPRECATION(x) x > > #endif > > ... as much. I agree it's pretty ugly. The one advantage it has is that we'd be informed of _other_ curl deprecations that might be more interesting to us. On the other hand, I don't know how useful those deprecations are going to be, as it depends on the timeframe. If the deprecation is added for the same version of libcurl that implements the alternative (which is roughly the case here), then we'd always be stuck supporting the old and new forms (old for backwards compatibility, and new to silence the deprecation warning). We care a lot more about the deprecation once the alternative has been around for a while, and/or the old way of doing things is about to be removed. And if we just wait until that removal, then we do not have to rely on deprecation warnings. The build will break just fine on its own. :) -Peff
