git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jeff King <peff@peff.net>
Date
Mar 12, 2017, 20:12 UTC
Message-ID
<20170312201237.wrstmhk5saiy52m4@sigill.intra.peff.net>
In-Reply-To
<20170312165119.3eokqse4uxdet6yd@genre.crustytoothpaste.net>
On Sun, Mar 12, 2017 at 04:51:19PM +0000, brian m. carlson wrote:
Show 13 quoted lines
> 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 that I might just do something like:
> 
>   #ifdef SHA1_HEADER
>   #include SHA1_HEADER
>   #else
>   #include "block-sha1/sha1.h"
>   #endif
> 
> That would be the smallest change, but probably not the best.

Yeah, if there is going to be a fallback it probably ought to be the internal one.

Show 16 quoted lines
> > Of course the sha1 header is just one of many such defines. It's the one
> > that is most visible because the result is syntactically valid without
> > it, but anything you compile without the Makefile's CFLAGS may be subtly
> > different than what the Makefile would produce. So arguably the Makefile
> > should be writing out a build-options.h with all of the values, and that
> > should get pulled in by git-compat-util.h.
> > 
> > I don't know if we want to go down that rabbit hole or not. I offer it
> > merely as an alternative. I'm OK with your patch as-is if you don't want
> > to dump any more time into it.
> 
> I'll take this patch for now and fix it up with the comment I mentioned
> below.  If someone wants to improve the situation down the line, then
> they can pick that up.
> 
> I assume I can apply your sign-off to the resulting patch?

Yes, it is OK to add my sign-off. The two things I was concerned about with my patch were:

  1. It does introduce an extra shell invocation on every "make", even
     if the file does not need to be rebuilt (though it is just one of
     many; GIT-BUILD-OPTIONS, etc).
  2. I wasn't sure if the dependencies were quite right. I _thought_ we
     should pick it up as an auto-dependency, but I don't think that
     works because we do our header dependencies as a side effect of the
     compile.
     So "make" didn't actually know to build hash.h until I made it a
     dependency of help.o. Which feels weird and hacky. It's really a
     dependency of _anything_ that includes cache.h.

So you may want to dig into that second one to make sure the result is sane, not racy, etc.

Show 7 quoted lines
> > +hash.h:
> > +	$(QUIET_GEN)echo '#include $(SHA1_HEADER)' >$@+ && \
> > +	{ cmp $@+ $@ >/dev/null 2>/dev/null || mv $@+ $@; }
> 
> I think here we'd want to also "rm -f $@+", so that we don't leave an
> extra file behind if we're up-to-date (which is the common case), much
> like we do for GIT-BUILD-OPTIONS.
Yeah, I agree that would be an improvement.
-Peff
Previous: brian m. carlsonNext: Junio C Hamano
Message 4 of 16 in “Move SHA-1 implementation selection into a header file”
  1. Move SHA-1 implementation selection into a header filebrian m. carlson, Mar 11, 2017
  2. Jeff KingMar 12, 2017
  3. brian m. carlsonMar 12, 2017
  4. Jeff KingMar 12, 2017
  5. Junio C HamanoMar 12, 2017
  6. Jonathan NiederMar 14, 2017
  7. Jeff KingMar 14, 2017
  8. Junio C HamanoMar 14, 2017
  9. Jeff KingMar 14, 2017
  10. Jonathan NiederMar 14, 2017
  11. Ramsay JonesMar 14, 2017
  12. brian m. carlsonMar 14, 2017
  13. Ramsay JonesMar 15, 2017
  14. Junio C HamanoMar 15, 2017
  15. Ramsay JonesMar 15, 2017
  16. Jonathan NiederMar 14, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.