Re: Deprecation warnings under XCode

[David Aguilar <davvid@gmail.com>]

On Tue, Dec 02, 2014 at 10:09:35PM -0500, Eric Sunshine wrote:
> On Tue, Dec 2, 2014 at 8:12 PM, Michael Blume <blume.mike@gmail.com> wrote:
> > On Tue, Dec 2, 2014 at 4:37 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> >> On Mon, Dec 1, 2014 at 1:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
> >>> I am not a Mac person, but is this about APPLE_COMMON_CRYPTO support
> >>> added in 4dcd7732 (Makefile: add support for Apple CommonCrypto
> >>> facility, 2013-05-19) and be4c828b (imap-send: eliminate HMAC
> >>> deprecation warnings on Mac OS X, 2013-05-19)? [...]
> >>> In the Makefile we seem to have this:
> >>>
> >>>     # Define NO_APPLE_COMMON_CRYPTO if you are building on Darwin/Mac OS X
> >>>     # and do not want to use Apple's CommonCrypto library.  This allows you
> >>>     # to provide your own OpenSSL library, for example from MacPorts.
> >>>
> >>> which makes it sound like using APPLE_COMMON_CRYPTO is the default
> >>> for Mac.  Perhaps those who do want to use CommonCrypto to avoid
> >>> warnings should not define that macro?
> >>
> >> It's been a long time [1] since I looked at it, but I believe that
> >> David's CommonCrypto patch series only replaced OpenSSL calls for
> >> which Apple had provided CommonCrypto replacements. If my memory is
> >> correct, there were still plenty of OpenSSL deprecations warnings
> >> remaining after his patches (the warnings which started this thread)
> >> even without defining NO_APPLE_COMMON_CRYPTO. Thus, David's patches
> >> reduced the number of warnings but did not fully eliminate them.
> >>
> >> Checking again, it still seems to be the case that Apple neglects to
> >> provide CommonCrypto replacements for these OpenSSL functions which
> >> Apple itself deprecated.
> >>
> >> [1]: http://thread.gmane.org/gmane.comp.version-control.git/224833
> >
> > If there's actually no way to address this, is there a simple way to
> > silence deprecation warnings only in this file? I only ask because
> > overall the git build seems to be extremely quiet, and it seems
> > valuable to preserve that, so that warnings we want to act on stick
> > out.
> 
> An individual developer can add '-Wno-deprecated-declarations' to
> CFLAGS to suppress these warnings, however, that's pretty much a
> sledge hammer which would impact deprecations from all included
> headers, not just Apple's. For this reason, we probably wouldn't want
> to make this the default.
> 
> The potentially lesser evil would be this small patch (minus Gmail
> whitespace damage) which disables the deprecation warnings only for
> Apple's headers:
> 
> ----- >8 -----
> diff --git a/git-compat-util.h b/git-compat-util.h
> index 400e921..709e84f 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -211,6 +211,8 @@ extern char *gitbasename(char *);
>  #endif
> 
>  #ifndef NO_OPENSSL
> +#define __AVAILABILITY_MACROS_USES_AVAILABILITY 0
> +#define MAC_OS_X_VERSION_MIN_REQUIRED MAC_OS_X_VERSION_10_6
>  #include <openssl/ssl.h>
>  #include <openssl/err.h>
>  #endif
> ----- >8 -----
> 
> It's still mildly heavy-handed, in that it could silence legitimate
> Apple deprecations, but it does give us a clean build with little
> fuss. An alternative would be to relegate these #defines to the Darwin
> section of the Makefile if placing them in git-compat-util.h seems too
> invasive.
> 
> Considering that Mac OS X is now at 10.10 and these deprecations
> commenced with Mac OS X 10.7 in July 2011 (3.5 years ago), and Apple
> still has not provided drop-in CommonCrypto equivalents, it seems
> unlikely that they will do so any time soon. Consequently, suppressing
> these otherwise unavoidable warnings may be the best we can do.
> 
> I'm willing to formalize and submit this as a proper patch if it's not
> considered too disgusting by the powers-that-be.


Tweaking those internal #defines can only come back to bite us
in the future when the functions are finally ripped out.

CommonCrypto seemed like a viable option at the time, but the
remaining deprecated functions don't have any replacements and
I wouldn't hold my breath waiting for CC to provide them.

It seems like a better approach might be something like [1].
I'd even suggest ripping out all of the commoncrypto stuff if it
makes the final curl-ified code easier to read.

libcurl 7.30.0 ships with OS X 10.9 (maybe even father back?)
so making imap-send default to using openssl for <= 10.8 and
curl for newer OS X seems like a good long-term solution.

[1] http://thread.gmane.org/gmane.comp.version-control.git/255171
-- 
David