Re: Deprecation warnings under XCode

[David Aguilar <davvid@gmail.com>]

On Wed, Dec 03, 2014 at 01:54:51PM +0100, Torsten Bögershausen wrote:
> On 12/03/2014 11:04 AM, David Aguilar wrote:
> >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.
> >
> >[1] http://thread.gmane.org/gmane.comp.version-control.git/255171
> Yes, but this patch needs 7.34 :-(
> 7.30 (as shipped with Mac OS X 10.9) is missing the CURLOPT_LOGIN_OPTIONS
> 
> Try
> rm imap-send.o
> NO_GETTEXT=yes NO_DARWIN_PORTS=Yes USE_CURL_FOR_IMAP_SEND=yes make
> imap-send.o


It looks like 10.10 Yosemite has curl 7.37.1 [1], so maybe it's
better there (I can't verify myself).

Silencing the warnings is a sensible thing to do for older
versions since it looks like there's a smooth upgrade path
via the curl patches.

My original caution was that not having the warnings would make
us forget that the issue existed, but (warning) silence is golden.

[1] http://curl.haxx.se/mail/archive-2014-10/0053.html
-- 
David