Re: Deprecation warnings under XCode

[Eric Sunshine <sunshine@sunshineco.com>]

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.