Re: Deprecation warnings under XCode

> 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