Re: [PATCH] ci: do not die on deprecated-declarations warning

[Jeff King <peff@peff.net>]

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