On Thu, May 16, 2013 at 11:18 PM, Eric Sunshine <sunsh...@sunshineco.com> wrote:
> On Wed, May 15, 2013 at 1:56 PM, Torsten Bögershausen <tbo...@web.de> wrote:
>> On 2013-05-15 09.11, David Aguilar wrote:
>>> +     ifndef NO_APPLE_COMMON_CRYPTO
>>> +             APPLE_COMMON_CRYPTO = YesPlease
>>> +     endif
>>>       NO_REGEX = YesPlease
>>>       PTHREAD_LIBS =
>>>  endif
>>> @@ -1389,10 +1396,16 @@ ifdef PPC_SHA1
>>>       LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o
>>>       LIB_H += ppc/sha1.h
>>>  else
>>> +     SHA1_HEADER = <CommonCrypto/CommonDigest.h>
>> Would it make sense to replace APPLE_COMMON_CRYPTO
>> In the spirit of other Makefile-defines becoming Compiler defines,
>> a random picked example:
>> ifdef NO_STRTOULL
>> endif
> Not necessarily. Unlike NO_STRTOULL and cousins,
> COMMON_DIGEST_FOR_OPENSSL is not a Git build tweak; it is merely a
> (public) implementation detail of the Apple header [1] to magically
> associate OpenSSL digest functions with CommonCrypto counterparts.
> It's not the only such macro recognized by the Apple headers. For
> instance, COMMON_DIGEST_FOR_RFC_1321 magically associates legacy MD5
> digest functions with CommonCrypto counterparts.
> Further, as Junio noted elsewhere, David is using CommonCrypto for
> HMAC replacements, not just for digest replacements, so a Makefile
> knob with DIGEST in its name is not really appropriate. More
> generally, David would like to find CommonCrypto replacements for all
> the OpenSSL functionality, so a Makefile knob named after DIGEST is
> too specific.
> These considerations motivated the original suggestion for a single
> Git Makefile knob to enable/disable, as a unit, all CommonCrypto
> replacements. Such a knob would naturally have COMMON_CRYPTO as part
> of its name.
> [1]: 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/include/CommonCrypto/CommonDigest.h

This is a nice justification for taking v5 of this series over v6.

Sorry for all the churn in this series, Junio.  I wrote v5 so I
certainly felt it was a good idea at the time, and I feel bad for not
having waited longer before sending out v6 (which is what was
eventually queued in "pu").

Do you have advice on how we should proceed?  :sigh: sorry for wasting
so much maintainer time on this series already.  If you need any
resends or anything please let me know.  This time I'll wait for a
strong opinion before firing off patches.

My opinion: yeah, v5's ([NO_]APPLE_COMMON_CRYPTO) was probably where
we should have stopped painting.  Hindsight is 20/20.  Luckily it
never left "pu".
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to