Like a recent GitHub CI run on linux-musl [1] shows, we seem to be getting a bunch of errors of the form: Error: http.c:1002:9: 'CURLOPT_REDIR_PROTOCOLS' is deprecated: since 7.85.0. Use CURLOPT_REDIR_PROTOCOLS_STR [-Werror=deprecated-declarations] For some of them, it may be reasonable to follow the deprecation notice and update the code, but some symbols like the above is not. According to the release table [2], 7.85.0 that deprecates CURLOPT_REDIR_PROTOCOLS was released on 2022-08-31, less than a year ago, and according to the symbols-in-versions table [3], CURLOPT_REDIR_PROTOCOLS_STR was introduced in 7.85.0, so it will make us incompatible with anything older than a year if we rewrote the call as the message suggests. For now, let's disable the deprecation warnings from libcURL altogether. Ideally we may still want to see them to learn about urgency of future need to rewrite our code (we only want to avoid -Werror to stop our build). [1] https://github.com/git/git/actions/runs/3915509922/jobs/6693756050 [2] https://curl.se/docs/releases.html [3] https://github.com/curl/curl/blob/master/docs/libcurl/symbols-in-versions Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx> --- config.mak.dev | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/config.mak.dev b/config.mak.dev index 981304727c..03a0bac8c9 100644 --- a/config.mak.dev +++ b/config.mak.dev @@ -69,6 +69,15 @@ DEVELOPER_CFLAGS += -Wno-missing-braces endif endif +# Libraries deprecate symbols while retaining them for a long time to +# keep software working with both older and newer versions of them. +# Getting warnings does help the developers' awareness, but we cannot +# afford to update too aggressively. E.g. CURLOPT_REDIR_PROTOCOLS_STR +# is only available in 7.85.0 that deprecates CURLOPT_REDIR_PROTOCOLS +# but we cannot rewrite the uses of the latter with the former until +# 7.85.0, which was released in August 2022, becomes ubiquitous. +DEVELOPER_CFLAGS += -DCURL_DISABLE_DEPRECATION + # Old versions of clang complain about initializaing a # struct-within-a-struct using just "{0}" rather than "{{0}}". This # error is considered a false-positive and not worth fixing, because -- 2.39.0-198-ga38d39a4c5
