Re: [RFC PATCH] Move SHA-1 implementation selection into a header file

2017-03-15 Thread Ramsay Jones
On 15/03/17 15:57, Junio C Hamano wrote: > Ramsay Jones writes: > >> On 14/03/17 23:46, brian m. carlson wrote: > > Since the SHA1_HEADER include is not defined in such a case, developers > see spurious errors when using these tools. Furthermore, while using a > macro as the ar

Re: [RFC PATCH] Move SHA-1 implementation selection into a header file

2017-03-15 Thread Junio C Hamano
Ramsay Jones writes: > On 14/03/17 23:46, brian m. carlson wrote: Since the SHA1_HEADER include is not defined in such a case, developers see spurious errors when using these tools. Furthermore, while using a macro as the argument to #include is permitted by C11, it isn't >>>

Re: [RFC PATCH] Move SHA-1 implementation selection into a header file

2017-03-14 Thread Ramsay Jones
On 14/03/17 23:46, brian m. carlson wrote: > On Tue, Mar 14, 2017 at 11:42:20PM +, Ramsay Jones wrote: >> >> >> On 14/03/17 20:44, Junio C Hamano wrote: >>> OK, then I'll queue this. The selection still goes to BASIC_CFLAGS >>> so the dependencies for re-compilation should be right, I'd thin

Re: [RFC PATCH] Move SHA-1 implementation selection into a header file

2017-03-14 Thread brian m. carlson
On Tue, Mar 14, 2017 at 11:42:20PM +, Ramsay Jones wrote: > > > On 14/03/17 20:44, Junio C Hamano wrote: > > OK, then I'll queue this. The selection still goes to BASIC_CFLAGS > > so the dependencies for re-compilation should be right, I'd think. > > > > -- >8 -- > > From: "brian m. carlson

Re: [RFC PATCH] Move SHA-1 implementation selection into a header file

2017-03-14 Thread Ramsay Jones
On 14/03/17 20:44, Junio C Hamano wrote: > OK, then I'll queue this. The selection still goes to BASIC_CFLAGS > so the dependencies for re-compilation should be right, I'd think. > > -- >8 -- > From: "brian m. carlson" > Date: Sat, 11 Mar 2017 22:28:18 + > Subject: [PATCH] hash.h: move SHA

Re: [RFC PATCH] Move SHA-1 implementation selection into a header file

2017-03-14 Thread Jonathan Nieder
Jeff King wrote: > On Tue, Mar 14, 2017 at 11:41:26AM -0700, Jonathan Nieder wrote: >> brian m. carlson wrote: >>> --- a/cache.h >>> +++ b/cache.h >>> @@ -10,8 +10,8 @@ >>> #include "trace.h" >>> #include "string-list.h" >>> #include "pack-revindex.h" >>> +#include "hash.h" >>> >>> -#include SH

Re: [RFC PATCH] Move SHA-1 implementation selection into a header file

2017-03-14 Thread Jonathan Nieder
Junio C Hamano wrote: > [jc: make BLK_SHA1 the fallback default as discussed on list, > e.g. <20170314201424.vccij5z2ortq4...@sigill.intra.peff.net>; also > remove SHA1_HEADER and SHA1_HEADER_SQ that are no longer used]. > > Signed-off-by: brian m. carlson > Signed-off-by: Junio C Hamano Review

Re: [RFC PATCH] Move SHA-1 implementation selection into a header file

2017-03-14 Thread Jeff King
On Tue, Mar 14, 2017 at 01:44:48PM -0700, Junio C Hamano wrote: > OK, then I'll queue this. The selection still goes to BASIC_CFLAGS > so the dependencies for re-compilation should be right, I'd think. Yeah, I think that part should be fine. > -- >8 -- > From: "brian m. carlson" > Date: Sat, 1

Re: [RFC PATCH] Move SHA-1 implementation selection into a header file

2017-03-14 Thread Junio C Hamano
OK, then I'll queue this. The selection still goes to BASIC_CFLAGS so the dependencies for re-compilation should be right, I'd think. -- >8 -- From: "brian m. carlson" Date: Sat, 11 Mar 2017 22:28:18 + Subject: [PATCH] hash.h: move SHA-1 implementation selection into a header file Many deve

Re: [RFC PATCH] Move SHA-1 implementation selection into a header file

2017-03-14 Thread Jeff King
On Tue, Mar 14, 2017 at 11:41:26AM -0700, Jonathan Nieder wrote: > brian m. carlson wrote: > > [...] > > --- a/cache.h > > +++ b/cache.h > > @@ -10,8 +10,8 @@ > > #include "trace.h" > > #include "string-list.h" > > #include "pack-revindex.h" > > +#include "hash.h" > > > > -#include SHA1_HEAD

Re: [RFC PATCH] Move SHA-1 implementation selection into a header file

2017-03-14 Thread Jonathan Nieder
Hi, brian m. carlson wrote: [...] > --- a/cache.h > +++ b/cache.h > @@ -10,8 +10,8 @@ > #include "trace.h" > #include "string-list.h" > #include "pack-revindex.h" > +#include "hash.h" > > -#include SHA1_HEADER For what it's worth, the bazel build tool doesn't like this '#include SHA1_HEADER

Re: [RFC PATCH] Move SHA-1 implementation selection into a header file

2017-03-12 Thread Jeff King
On Sun, Mar 12, 2017 at 04:51:19PM +, brian m. carlson wrote: > Yeah, my goal was basically to pass -fsyntax-only, not to produce useful > object files. My patch does basically require that the user have > OpenSSL installed, but I do, so it doesn't matter. > > I considered after the fact tha

Re: [RFC PATCH] Move SHA-1 implementation selection into a header file

2017-03-12 Thread Junio C Hamano
Jeff King writes: > diff --git a/Makefile b/Makefile > index 9f0eae428..0d65d50e9 100644 > --- a/Makefile > +++ b/Makefile > @@ -690,6 +690,7 @@ XDIFF_LIB = xdiff/lib.a > VCSSVN_LIB = vcs-svn/lib.a > > GENERATED_H += common-cmds.h > +GENERATED_H += hash.h > ... > -BASIC_CFLAGS += -DSHA1_HEADE

Re: [RFC PATCH] Move SHA-1 implementation selection into a header file

2017-03-12 Thread brian m. carlson
On Sun, Mar 12, 2017 at 09:01:49AM -0400, Jeff King wrote: > On Sat, Mar 11, 2017 at 10:28:18PM +, brian m. carlson wrote: > > > Many developers use functionality in their editors that allows for quick > > syntax checks, including warning about questionable constructs. This > > functionality

Re: [RFC PATCH] Move SHA-1 implementation selection into a header file

2017-03-12 Thread Jeff King
On Sat, Mar 11, 2017 at 10:28:18PM +, brian m. carlson wrote: > Many developers use functionality in their editors that allows for quick > syntax checks, including warning about questionable constructs. This > functionality allows rapid development with fewer errors. However, such > function

[RFC PATCH] Move SHA-1 implementation selection into a header file

2017-03-11 Thread brian m. carlson
Many developers use functionality in their editors that allows for quick syntax checks, including warning about questionable constructs. This functionality allows rapid development with fewer errors. However, such functionality generally does not allow the specification of project-specific define