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

Re: [RFC/PATCH 0/3] Thinning the git toplevel directory

From
Jeff King <peff@peff.net>
Date
Feb 23, 2011, 04:51 UTC
Message-ID
<20110223045143.GA11846@sigill.intra.peff.net>
In-Reply-To
<7v4o7vdfz2.fsf@alter.siamese.dyndns.org>
On Tue, Feb 22, 2011 at 11:30:41AM -0800, Junio C Hamano wrote:
Show 8 quoted lines
> > It is one less thing to need to do when writing new code, and one less
> > thing to have silly textual conflicts on. It probably doesn't matter
> > that much, though; we don't actually add new files or commands all that
> > often.
> 
> Yeah, you would need to add an entry to the builtin command list yourself
> anyway, until we also autogenerate it, which I doubt will ever happen nor
> is necessarily a good idea.

You also have to add the declaration to builtin.h. It is kind of a hassle to have to add it in three places (Makefile, command list, and declaration) in addition to the actual code. But again, it's not like we do this that often.

Show 7 quoted lines
> > Speaking of Makefiles, one downside to all of this directory
> > segmentation is that you can't run "make" from the subdirectories.
> 
> I had an impression that "make -C lib/" would be one of the goals, iow,
> when we split the directory structure, the next step would be to split the
> top-level Makefile so that each directory is covered by its own Makefile,
> just like Documentation/ is already usable that way.

Ugh. I am not thrilled at the prospect of more recursive make. As it is now, we have already dealt with bugs from the little bit of recursion there is (e.g., propagating information between Makefiles) and weird heisenbugs (I still occasionally get build failures on recursing into the perl subdir during a parallel make). And then of course it's easy to misuse; running "make" in t/ is not necessarily testing the latest version. In my experience recursive make always comes with this sort of flakiness.

Right now the actual C build process is entirely in the top-level Makefile. I really like that I can trust it to handle dependencies correctly, because it means I can bisect without resorting to "make clean" for each step.

-Peff
Previous: Sverre RabbelierNext: Jonathan Nieder
Message 35 of 54 in “Move test-*.c to test/ subdirectory”
  1. Move test-*.c to test/ subdirectoryNguyễn Thái Ngọc Duy, Feb 9, 2011
  2. Nguyen Thai Ngoc DuyFeb 9, 2011
  3. Junio C HamanoFeb 9, 2011
  4. Move test-* to t/helper/ subdirectoryNguyễn Thái Ngọc Duy, Feb 10, 2011
  5. 0/3 Thinning the git toplevel directoryJonathan Nieder, Feb 18, 2011
  6. 1/3 Move libgit.a sources into a libgit/ subdirectoryJonathan Nieder, Feb 18, 2011
  7. Nguyen Thai Ngoc DuyFeb 18, 2011
  8. Jonathan NiederFeb 18, 2011
  9. Jeff KingFeb 18, 2011
  10. Jonathan NiederFeb 18, 2011
  11. Nguyen Thai Ngoc DuyFeb 18, 2011
  12. 2/3 Move test-* into a test-programs/ subdirectoryJonathan Nieder, Feb 18, 2011
  13. 3/3 Move header files into a include/ subdirectoryJonathan Nieder, Feb 18, 2011
  14. Nguyen Thai Ngoc DuyFeb 18, 2011
  15. 6/3 Move remaining header files into a include/ subdirectoryJonathan Nieder, Feb 18, 2011
  16. 4/3 compat: do not use relative paths to refer to git-compat-util.h et alJonathan Nieder, Feb 18, 2011
  17. 5/3 block-sha1: do not use relative path for git-compat-util.hJonathan Nieder, Feb 18, 2011
  18. 6/3 Move git-compat-util.h, strbuf.h, and cache.h to include/Jonathan Nieder, Feb 18, 2011
  19. Nguyen Thai Ngoc DuyFeb 18, 2011
  20. 9/3 Thinning the git toplevel directoryJonathan Nieder, Feb 18, 2011
  21. 7/3 Move test-sha1.sh to test-programs/Jonathan Nieder, Feb 18, 2011
  22. 8/3 Move build helpers to scripts/ subdirectoryJonathan Nieder, Feb 18, 2011
  23. 9/3 Move non-builtin git commands and script libraries to a subdirectoryJonathan Nieder, Feb 18, 2011
  24. Jonathan NiederFeb 18, 2011
  25. Jeff KingFeb 18, 2011
  26. Jonathan NiederFeb 18, 2011
  27. Nguyen Thai Ngoc DuyFeb 18, 2011
  28. Junio C HamanoFeb 18, 2011
  29. Jonathan NiederFeb 19, 2011
  30. Sverre RabbelierFeb 19, 2011
  31. The git_remote_helpers package (Re: [RFC/PATCH 0/3] Thinning the git toplevel directory)Jonathan Nieder, Feb 19, 2011
  32. Jeff KingFeb 22, 2011
  33. Junio C HamanoFeb 22, 2011
  34. Sverre RabbelierFeb 22, 2011
  35. Jeff KingFeb 23, 2011
  36. Jonathan NiederFeb 23, 2011
  37. Jeff KingFeb 23, 2011
  38. Recursive make and variations on the themeJonathan Nieder, Feb 23, 2011
  39. Junio C HamanoFeb 23, 2011
  40. Nicolas PitreFeb 23, 2011
  41. Drew NorthupFeb 23, 2011
  42. Nicolas PitreFeb 24, 2011
  43. Drew NorthupFeb 24, 2011
  44. Nicolas PitreFeb 24, 2011
  45. Jeff KingFeb 24, 2011
  46. Drew NorthupFeb 24, 2011
  47. Piotr KrukowieckiFeb 19, 2011
  48. Junio C HamanoFeb 19, 2011
  49. Jonathan NiederFeb 19, 2011
  50. Piotr KrukowieckiFeb 19, 2011
  51. Piotr KrukowieckiFeb 19, 2011
  52. Advertising the prebuilt htmldocs and manpagesJonathan Nieder, Feb 19, 2011
  53. Junio C HamanoFeb 20, 2011
  54. Jonathan NiederFeb 20, 2011

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.