[PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11

2016-10-16 Thread larsxschneider
From: Lars Schneider Apple removed the OpenSSL header files in macOS 10.11 and above. OpenSSL was deprecated since macOS 10.7. Set `NO_OPENSSL` and `APPLE_COMMON_CRYPTO` to `YesPlease` as default for macOS. Make it possible to override this and use OpenSSL by defining `DARWIN_OPENSSL`. Original

Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11

2016-10-17 Thread Jeff King
On Sun, Oct 16, 2016 at 05:25:49PM -0700, larsxschnei...@gmail.com wrote: > From: Lars Schneider > > Apple removed the OpenSSL header files in macOS 10.11 and above. OpenSSL > was deprecated since macOS 10.7. > > Set `NO_OPENSSL` and `APPLE_COMMON_CRYPTO` to `YesPlease` as default for > macOS.

Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11

2016-11-06 Thread Lars Schneider
> On 17 Oct 2016, at 11:50, Jeff King wrote: > > On Sun, Oct 16, 2016 at 05:25:49PM -0700, larsxschnei...@gmail.com wrote: > >> From: Lars Schneider >> >> Apple removed the OpenSSL header files in macOS 10.11 and above. OpenSSL >> was deprecated since macOS 10.7. >> >> Set `NO_OPENSSL` and `

Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11

2016-11-07 Thread Jeff King
On Sun, Nov 06, 2016 at 08:35:04PM +0100, Lars Schneider wrote: > Good point. I think I found an even easier way to achieve the same. > What do you think about the patch below? > > [...] > > diff --git a/Makefile b/Makefile > index 9d6c245..f53fcc9 100644 > --- a/Makefile > +++ b/Makefile > @@ -10

Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11

2016-11-07 Thread Paul Smith
On Mon, 2016-11-07 at 12:26 -0500, Jeff King wrote: > I have in the back of my mind a fear that it is harder to unset a > make variable than it is to override it with a new value (which is > what you'd want to do here to turn openssl back on), It depends on what you mean by "unset". If you mean i

Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11

2016-11-07 Thread Jeff King
On Mon, Nov 07, 2016 at 12:36:34PM -0500, Paul Smith wrote: > On Mon, 2016-11-07 at 12:26 -0500, Jeff King wrote: > > I have in the back of my mind a fear that it is harder to unset a > > make variable than it is to override it with a new value (which is > > what you'd want to do here to turn open

Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11

2016-11-07 Thread Paul Smith
On Mon, 2016-11-07 at 12:46 -0500, Jeff King wrote: > Specifically I wanted to make sure that > >   FOO = bar >   FOO = >   ifdef FOO >   ... something ... >   endif > > works as if FOO had never been set in the first place. Which it seems > to, at least in GNU make (and that is the only one we s

Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11

2016-11-09 Thread Torsten Bögershausen
On 07.11.16 18:26, Jeff King wrote: > On Sun, Nov 06, 2016 at 08:35:04PM +0100, Lars Schneider wrote: > >> Good point. I think I found an even easier way to achieve the same. >> What do you think about the patch below? >> >> [...] >> >> diff --git a/Makefile b/Makefile >> index 9d6c245..f53fcc9 10

Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11

2016-11-09 Thread Lars Schneider
> On 09 Nov 2016, at 09:18, Torsten Bögershausen wrote: > > On 07.11.16 18:26, Jeff King wrote: >> On Sun, Nov 06, 2016 at 08:35:04PM +0100, Lars Schneider wrote: >> >>> Good point. I think I found an even easier way to achieve the same. >>> What do you think about the patch below? >>> >>> [..

Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11

2016-11-09 Thread Torsten Bögershausen
On 09.11.16 10:29, Lars Schneider wrote: > >> On 09 Nov 2016, at 09:18, Torsten Bögershausen wrote: >> >> On 07.11.16 18:26, Jeff King wrote: >>> On Sun, Nov 06, 2016 at 08:35:04PM +0100, Lars Schneider wrote: >>> Good point. I think I found an even easier way to achieve the same. What