{"thread":{"id":"1345","subject":"[PATCH/RFC] \"Recursive Make considered harmful\"","startedAt":"2005-07-27T08:39:10Z","lastAt":"2005-07-29T09:12:32Z","messageCount":16,"participants":["Ryan Anderson","A Large Angry SCM","Kirby C. Bohling","Junio C Hamano","Matthias Urlichs","Petr Baudis","Sam Ravnborg","Timo Hirvonen"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"6475","messageId":"20050727083910.GG19290@mythryan2.michonline.com","threadId":"1345","inReplyTo":null,"subject":"[PATCH/RFC] \"Recursive Make considered harmful\"","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2005-07-27T08:39:10Z","receivedAt":"2005-07-27T08:39:10Z","isPatch":true,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"Convert build process from recurse Make to a single Make\n\nThe old Makefiles in Documentation/ and tools/ still exist until we feel\nconfident that I didn't miss anything on this conversion.\n\nMost of this patch is fixing up the main Makefile to avoid overlapping\ntarget names.\n\nSigned-off-by: Ryan Anderson <ryan@michonline.com>\n---\n\n Documentation/Makefile.inc |   50 ++++++++++++++++++++++++++++++++++++++++++++\n Makefile                   |   24 ++++++++++++++-------\n tools/Makefile.inc         |   12 +++++++++++\n 3 files changed, 78 insertions(+), 8 deletions(-)\n create mode 100644 Documentation/Makefile.inc\n create mode 100644 tools/Makefile.inc\n\n003afd3ed1f83b4533b628182fa16c9ab0dc0467\ndiff --git a/Documentation/Makefile.inc b/Documentation/Makefile.inc\nnew file mode 100644\n--- /dev/null\n+++ b/Documentation/Makefile.inc\n@@ -0,0 +1,50 @@\n+MAN1_TXT=$(wildcard Documentation/git-*.txt)\n+MAN7_TXT=Documentation/git.txt\n+\n+DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN7_TXT))\n+\n+DOC_MAN1=$(patsubst %.txt,%.1,$(MAN1_TXT))\n+DOC_MAN7=$(patsubst %.txt,%.7,$(MAN7_TXT))\n+\n+mandir=$(prefix)/man\n+man1=$(mandir)/man1\n+man7=$(mandir)/man7\n+\n+#\n+# Please note that there is a minor bug in asciidoc.\n+# The version after 6.0.3 _will_ include the patch found here:\n+#   http://marc.theaimsgroup.com/?l=git&m=111558757202243&w=2\n+#\n+# Until that version is released you may have to apply the patch\n+# yourself - yes, all 6 characters of it!\n+#\n+\n+all-doc: html man\n+\n+html: $(DOC_HTML)\n+\n+\n+man: man1 man7\n+man1: $(DOC_MAN1)\n+man7: $(DOC_MAN7)\n+\n+install-doc:\n+\t$(INSTALL) -m755 -d $(dest)/$(man1) $(dest)/$(man7)\n+\t$(INSTALL) $(DOC_MAN1) $(dest)/$(man1)\n+\t$(INSTALL) $(DOC_MAN7) $(dest)/$(man7)\n+\n+# 'include' dependencies\n+Documentation/git-diff-%.txt: Documentation/diff-format.txt Documentation/diff-options.txt\n+\ttouch $@\n+\n+clean-doc:\n+\trm -f Documentation/*.xml Documentation/*.html Documentation/*.1 Documentation/*.7\n+\n+%.html : %.txt\n+\tasciidoc -b xhtml11 -d manpage $<\n+\n+%.1 %.7 : %.xml\n+\txmlto -o Documentation/ man $<\n+\n+%.xml : %.txt\n+\tasciidoc -b docbook -d manpage $<\ndiff --git a/Makefile b/Makefile\n--- a/Makefile\n+++ b/Makefile\n@@ -54,9 +54,17 @@ PROG=   git-update-cache git-diff-files \n \tgit-show-index git-daemon git-var git-peek-remote \\\n \tgit-update-server-info git-show-rev-cache git-build-rev-cache\n \n-all: $(PROG)\n+include Documentation/Makefile.inc\n+include tools/Makefile.inc\n \n-install: $(PROG) $(SCRIPTS)\n+all: all-bin all-doc\n+all-bin: $(PROG)\n+#all-tools\n+\n+install: install-bin install-doc\n+#install-tools\n+\n+install-bin: $(PROG) $(SCRIPTS)\n \t$(INSTALL) -m755 -d $(dest)$(bin)\n \t$(INSTALL) $(PROG) $(SCRIPTS) $(dest)$(bin)\n \n@@ -204,20 +212,20 @@ rpm: dist\n test: all\n \t$(MAKE) -C t/ all\n \n-doc:\n-\t$(MAKE) -C Documentation all\n+doc: all-doc\n+#\t$(MAKE) -C Documentation all\n \n-install-tools:\n+install-toolsxx:\n \t$(MAKE) -C tools install\n \n-install-doc:\n+install-docxx:\n \t$(MAKE) -C Documentation install\n \n-clean:\n+clean: clean-doc clean-tools\n \trm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(LIB_FILE)\n \trm -f git-core-*.tar.gz git-core.spec\n \t$(MAKE) -C tools/ clean\n-\t$(MAKE) -C Documentation/ clean\n \n backup: clean\n \tcd .. ; tar czvf dircache.tar.gz dir-cache\n+\ndiff --git a/tools/Makefile.inc b/tools/Makefile.inc\nnew file mode 100644\n--- /dev/null\n+++ b/tools/Makefile.inc\n@@ -0,0 +1,12 @@\n+#\n+# Make Linus git-tools\n+#\n+\n+PROG += $(addprefix tools/,git-mailsplit git-mailinfo)\n+SCRIPTS += $(addprefix tools/,git-applymbox git-applypatch)\n+\n+tools/git-%: tools/%.c\n+\t$(CC) $(CFLAGS) -o $@ $(filter %.c,$^)\n+\n+clean-tools:\n+\trm -f tools/*.o\n\n-- \n\nRyan Anderson\n  sometimes Pug Majere\n"},{"id":"6479","messageId":"42E79946.2020309@gmail.com","threadId":"1345","inReplyTo":"20050727083910.GG19290@mythryan2.michonline.com","subject":"Re: [PATCH/RFC] \"Recursive Make considered harmful\"","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2005-07-27T14:25:10Z","receivedAt":"2005-07-27T14:25:10Z","isPatch":true,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Ryan Anderson wrote:\n> Convert build process from recurse Make to a single Make\n> \n\nPlease explain the rational for this.\n"},{"id":"6480","messageId":"20050727143720.GG7410@birddog.com","threadId":"1345","inReplyTo":"42E79946.2020309@gmail.com","subject":"Re: [PATCH/RFC] \"Recursive Make considered harmful\"","fromName":"Kirby C. Bohling","fromEmail":"kbohling@birddog.com","sentAt":"2005-07-27T14:37:21Z","receivedAt":"2005-07-27T14:37:21Z","isPatch":true,"sender":{"key":"kbohling@birddog.com","avatar":null},"body":"On Wed, Jul 27, 2005 at 10:25:10AM -0400, A Large Angry SCM wrote:\n> Ryan Anderson wrote:\n> >Convert build process from recurse Make to a single Make\n> >\n> \n> Please explain the rational for this.\n\nI'm new to the list, but given the subject, I'm fairly confident\nit's this.\n\nhttp://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html\n\nI'm a convert.  I converted a fairly large code base at work, and it\nwas a huge boon for productivity.  Build times dropped dramatically\n(from 40 seconds to 2-5 for a single file change).\n\nHe used the exact wording just about everyone dones when referring\nto it conceptually.  It's easy to google for support and rebuttal:\n\nhttp://www.google.com/search?hl=en&q=Recursive+Make+considered+harmful&btnG=Google+Search\n\n    Thanks,\n        Kirby\n"},{"id":"6482","messageId":"42E7A8FC.3080904@gmail.com","threadId":"1345","inReplyTo":"20050727143720.GG7410@birddog.com","subject":"Re: [PATCH/RFC] \"Recursive Make considered harmful\"","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2005-07-27T15:32:12Z","receivedAt":"2005-07-27T15:32:12Z","isPatch":true,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Kirby C. Bohling wrote:\n> On Wed, Jul 27, 2005 at 10:25:10AM -0400, A Large Angry SCM wrote:\n>>Ryan Anderson wrote:\n>>>Convert build process from recurse Make to a single Make\n>>>\n>>Please explain the rational for this.\n> \n> I'm new to the list, but given the subject, I'm fairly confident\n> it's this.\n> \n> http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html\n> \n...\n> \n> He used the exact wording just about everyone dones when referring\n> to it conceptually.  It's easy to google for support and rebuttal:\n> \n> http://www.google.com/search?hl=en&q=Recursive+Make+considered+harmful&btnG=Google+Search\n\nThanks for the references.\n\nA quick read of the paper and some of the rebuttals make me think that \neither way (recursive/non-recursive):\n\t* require about the same amount of makefile/dependency maintenance work \nfrom developers.\n\t* allow developers to be lazy in different ways with \nmakefiles/dependencies.\n\t* achieves the same end.\n\nThe non-recursive make method may have a small advantage for developers \nusing Git for their SCM because the Git operations are also performed at \nthe top level due to Git's design.\n"},{"id":"6486","messageId":"7v4qafrk8w.fsf@assigned-by-dhcp.cox.net","threadId":"1345","inReplyTo":"20050727083910.GG19290@mythryan2.michonline.com","subject":"Re: [PATCH/RFC] \"Recursive Make considered harmful\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-27T21:50:55Z","receivedAt":"2005-07-27T21:50:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ryan Anderson <ryan@michonline.com> writes:\n\n> 003afd3ed1f83b4533b628182fa16c9ab0dc0467\n> diff --git a/Documentation/Makefile.inc b/Documentation/Makefile.inc\n> new file mode 100644\n> --- /dev/null\n> +++ b/Documentation/Makefile.inc\n> @@ -0,0 +1,50 @@\n> +MAN1_TXT=$(wildcard Documentation/git-*.txt)\n> +MAN7_TXT=Documentation/git.txt\n> +\n>...\n\nWhile I do not have strong objections to make the build process\ngo faster, it is somewhat disturbing that the Makefile pieces\nmaintained in subdirectories need to name things they touch\nusing paths that include the subdirectory names.  I do not have\na better alternative to suggest, though...\n\nI'd keep it in the proposed updates branch for now and wait for\na bit until discussions on the list die out.\n"},{"id":"6488","messageId":"42E8058B.7070907@gmail.com","threadId":"1345","inReplyTo":"7v4qafrk8w.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC] \"Recursive Make considered harmful\"","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2005-07-27T22:07:07Z","receivedAt":"2005-07-27T22:07:07Z","isPatch":true,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> While I do not have strong objections to make the build process\n> go faster, it is somewhat disturbing that the Makefile pieces\n> maintained in subdirectories need to name things they touch\n> using paths that include the subdirectory names.  I do not have\n> a better alternative to suggest, though...\n\nFor a project the size of Git, is there any real benefit to this change?\n\nBesides pathing issues, you also have to aware that all identifiers in \nthe included makefile fragments will be global.\n\nI don't object to the change but I see it as trading one maintenance \nissue for another.\n"},{"id":"6492","messageId":"7v64uvh0mo.fsf@assigned-by-dhcp.cox.net","threadId":"1345","inReplyTo":"7v4qafrk8w.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC] \"Recursive Make considered harmful\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-28T07:04:47Z","receivedAt":"2005-07-28T07:04:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ryan, I am dropping this patch, at least for now, after keeping\nit in the \"pu\" (proposed updates) branch and using it myself.\nThere are two complaints from me.\n\nI am used to \"make bin=$HOME/bin/i386 install install-tools\",\nwhich the patch breaks (I do not want to build docs for myself).\nThis is minor; I could say \"install-bin install-toolsxx\"\ninstead.\n\nI do not deal with RPM packages myself, but guessing by reading\ngit-core.spec.in, I think it relies on the install target not\ntouching the documentation, in order for it to be able to build\ndoc-full and/or doc-less binary packages.  The patch makes\ninstall target to also build and install docs.\n\nThe Debian build is not affected because it does not produce\nseparate git-core and doc-git-core packages[*1*]; probably this\nwas the reason you did not notice this.\n\nI think what is installed from the toplevel and what comes from\ntools/ subdirectory are divided mostly for historical reasons\nand nothing else[*2*], and I do not mind the install target\ndepending on install-bin and install-tools, but I suspect that\nbinary packaging folks would appreciate to have a separate doc\ntarget that is not done by a normal install.\n\nSpeeding up the build procedure by defining dependencies\ncorrectly is a worthy goal.  Personally I feel a low hanging\nfruit is in the main Makefile, before worrying about the make\nrecursion.  Many things are in libgit.a and when I touch\nsomething only relevant to small number of things, say\ncsum-file.c, all \"git-%: %.c\" programs are recompiled and\nrelinked, even most of them do not link with csum-file.o (this\nparticular one is only used by git-pack-objects, by the way).\n\n[Footnote]\n\n*1* Which, BTW, would be the Debian way, if I am not mistaken.\n\n*2* Although one _could_ argue that tools/ is primarily meant\nfor \"project lead\" role users who accept and incorporate patches\nobtained via e-mails.\n"},{"id":"6494","messageId":"pan.2005.07.28.07.45.31.245357@smurf.noris.de","threadId":"1345","inReplyTo":"7v64uvh0mo.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC] \"Recursive Make considered harmful\"","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-07-28T07:45:31Z","receivedAt":"2005-07-28T07:45:31Z","isPatch":true,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi, Junio C Hamano wrote:\n\n> The Debian build is not affected because it does not produce\n> separate git-core and doc-git-core packages[*1*]; probably this\n> was the reason you did not notice this.\n\ngit-core-doc, actually.\n\nDebian does that only if the documentation is substantial. Even then,\nmanpages may not be segregated into -doc.\n\nHowever, I *would* segregate gitk into its own Debian package, because\nit requires wish et al., which would pull a large chunk of X11 stuff,\nwhich people may not want on their server.\n\nPatch follows separately -- I'll have to pull it from my other mess\n(which includes yet another Debian package for Cogito ;-).\n\n-- \nMatthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de\nDisclaimer: The quote was selected randomly. Really. | http://smurf.noris.de\n - -\nA zealot's stones will break my bones, but gods will never hurt me.\n"},{"id":"6496","messageId":"20050728075115.GB18907@pasky.ji.cz","threadId":"1345","inReplyTo":"42E8058B.7070907@gmail.com","subject":"Re: [PATCH/RFC] \"Recursive Make considered harmful\"","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-28T07:51:15Z","receivedAt":"2005-07-28T07:51:15Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Jul 28, 2005 at 12:07:07AM CEST, I got a letter\nwhere A Large Angry SCM <gitzilla@gmail.com> told me that...\n> Junio C Hamano wrote:\n> >While I do not have strong objections to make the build process\n> >go faster, it is somewhat disturbing that the Makefile pieces\n> >maintained in subdirectories need to name things they touch\n> >using paths that include the subdirectory names.  I do not have\n> >a better alternative to suggest, though...\n> \n> For a project the size of Git, is there any real benefit to this change?\n> \n> Besides pathing issues, you also have to aware that all identifiers in \n> the included makefile fragments will be global.\n> \n> I don't object to the change but I see it as trading one maintenance \n> issue for another.\n\nI'd also argue that generally, larger files are inherently harder to\nmaintain, and having all the targets for all the subdirectories in a\nsingle file sounds nightmarish. (OTOH, by now you probably know that I'm\na keep-it-as-local-as-possible junkie.)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"6497","messageId":"pan.2005.07.28.09.40.17.664900@smurf.noris.de","threadId":"1345","inReplyTo":"20050728075115.GB18907@pasky.ji.cz","subject":"Re: [PATCH/RFC] \"Recursive Make considered harmful\"","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-07-28T09:40:19Z","receivedAt":"2005-07-28T09:40:19Z","isPatch":true,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi, Petr Baudis wrote:\n\n> having all the targets for all the subdirectories in a\n> single file sounds nightmarish\n\nwhich is why you'd include Makefile[.inc] snippets from subdirectories\ninstead.\n\n-- \nMatthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de\nDisclaimer: The quote was selected randomly. Really. | http://smurf.noris.de\n - -\nThe only difference between a fool and a criminal who attacks a system is\nthat the fool attacks unpredictably and on a broader front.\n\t\t\t\t\t-- Tom Gibb\n"},{"id":"6515","messageId":"7vk6jac2cv.fsf@assigned-by-dhcp.cox.net","threadId":"1345","inReplyTo":"pan.2005.07.28.07.45.31.245357@smurf.noris.de","subject":"Re: [PATCH/RFC] \"Recursive Make considered harmful\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-28T16:38:40Z","receivedAt":"2005-07-28T16:38:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthias Urlichs <smurf@smurf.noris.de> writes:\n\n> However, I *would* segregate gitk into its own Debian package, because\n> it requires wish et al., which would pull a large chunk of X11 stuff,\n> which people may not want on their server.\n\nWhile I agree gitk should not come as part of git package, this\nbrings up a different issue.\n\nIdeally, I'd want to see gitk packaged from its repository\nkernel.org:/pub/scm/gitk/git.git/ Paul Mackerras maintains, not\nfrom GIT one which _will_ lag behind.\n\nWe have a copy of gitk in git repository because Linus \"merged\"\nit as \"the coolest merge ever\" example.  While I intend to keep\nupdating from gitk repository from time to time only because I\ndo not want to ship ancient version of it, I see a big problem\ndown the road.  What happens if someday Paul wanted to have a\ntoplevel Makefile of his own, or if somebody sends him a patch\nto add debian/rules file to build a separate gitk package from\nits own source tree?  Pulling/merging from gitk repo to update\nthe copy git has suddenly becomes a nightmere.\n\nWhile I _do_ rely on gitk in my git work, and I _do_ like its\nsimplicity (just a single file right now), my longer term\npreference is to drop the copy we have in git tree and treat it\njust like the other repository browser, qgit.  Our documentation\nshould point people at it as part of the Porcelain suite.\n"},{"id":"6517","messageId":"42E91151.7060004@gmail.com","threadId":"1345","inReplyTo":"7vk6jac2cv.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC] \"Recursive Make considered harmful\"","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2005-07-28T17:09:37Z","receivedAt":"2005-07-28T17:09:37Z","isPatch":true,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Junio C Hamano wrote:\n...\n> While I agree gitk should not come as part of git package, this\n> brings up a different issue.\n> \n> Ideally, I'd want to see gitk packaged from its repository\n> kernel.org:/pub/scm/gitk/git.git/ Paul Mackerras maintains, not\n> from GIT one which _will_ lag behind.\n> \n...\n> \n> While I _do_ rely on gitk in my git work, and I _do_ like its\n> simplicity (just a single file right now), my longer term\n> preference is to drop the copy we have in git tree and treat it\n> just like the other repository browser, qgit.  Our documentation\n> should point people at it as part of the Porcelain suite.\n\nThen this should happen sooner rather than later.\n"},{"id":"6548","messageId":"20050729065335.GA32263@mythryan2.michonline.com","threadId":"1345","inReplyTo":"7v4qafrk8w.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC] \"Recursive Make considered harmful\"","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2005-07-29T06:53:35Z","receivedAt":"2005-07-29T06:53:35Z","isPatch":true,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"On Wed, Jul 27, 2005 at 02:50:55PM -0700, Junio C Hamano wrote:\n> Ryan Anderson <ryan@michonline.com> writes:\n> \n> > 003afd3ed1f83b4533b628182fa16c9ab0dc0467\n> > diff --git a/Documentation/Makefile.inc b/Documentation/Makefile.inc\n> > new file mode 100644\n> > --- /dev/null\n> > +++ b/Documentation/Makefile.inc\n> > @@ -0,0 +1,50 @@\n> > +MAN1_TXT=$(wildcard Documentation/git-*.txt)\n> > +MAN7_TXT=Documentation/git.txt\n> > +\n> >...\n> \n> While I do not have strong objections to make the build process\n> go faster, it is somewhat disturbing that the Makefile pieces\n> maintained in subdirectories need to name things they touch\n> using paths that include the subdirectory names.  I do not have\n> a better alternative to suggest, though...\n> \n> I'd keep it in the proposed updates branch for now and wait for\n> a bit until discussions on the list die out.\n\nSorry for taking so long to respond here - I've probably got 2 or 3\ngeneral replies to make on this thread, but basically, I truly intended\nit as a RFC.\n\nI think the best justification for the end goal of the process I was\nthinking of starting is this:\n\n\t$ git clone -l git-linus git-example\n\tdefaulting to local storage area\n\t0 blocks\n\t$ cd git-example\n\t$ git checkout\n\t$ ls | wc -l\n\t154\n\nI've been spending some time trying to think out what qualifies as a\n\"tool\" and what is \"core\", etc.  I think it wouldn't be a bad idea to\nthink about restructuring things a bit so that all the little \"helper\"\nscripts we keep adding don't fill up the top level directory.\n\nI think I'm going to rethink this, a bit more.  I'm unhappy with how I\nhad to edit the sub-dir Makefiles to include directory names.  Sam, if\nyou happen to be reading this, feel free to help out!\n\nI'm almost thinking that something like:\n\n\tPROGS := \n\tSCRIPTS :=\n\tinclude x/Makefile.inc\n\tPROGRAMS += $(addprefix x/,$PROGS)\n\tALL_SCRIPTS += $(addprefix x/,$SCRIPTS)\n\nin the top-level Makefile might be the cleanest way to keep the\nsubdirectory ones simpler - but that's still somewhat distasteful, and\nonly fixes up one part of the problem.\n\nAnyway, I'll come back to this later when I've got some of the follow-up\nissues sorted out, like what to do with the directory structure.\n\n-- \n\nRyan Anderson\n  sometimes Pug Majere\n"},{"id":"6553","messageId":"20050729073134.GA6507@mars.ravnborg.org","threadId":"1345","inReplyTo":"20050729065335.GA32263@mythryan2.michonline.com","subject":"Re: [PATCH/RFC] \"Recursive Make considered harmful\"","fromName":"Sam Ravnborg","fromEmail":"sam@ravnborg.org","sentAt":"2005-07-29T07:31:34Z","receivedAt":"2005-07-29T07:31:34Z","isPatch":true,"sender":{"key":"sam@ravnborg.org","avatar":"https://gravatar.com/avatar/168a912606ed0742d840bb365e3cc21db390c36531a58341dc7a069cc1f15f62?d=mp&s=160"},"body":"> > While I do not have strong objections to make the build process\n> > go faster, it is somewhat disturbing that the Makefile pieces\n> > maintained in subdirectories need to name things they touch\n> > using paths that include the subdirectory names.  I do not have\n> > a better alternative to suggest, though...\n\nIf the goal is to speed up the build process the only sane way is to fix\nthe dependencies. In kbuild fixdep is used to parse the .c file and it\nlocates all references to .h files (recursive) and also detects any\nusage of CONFIG_ symbols.\nThis part should be relative straightforward to include in git.\n\n> I think I'm going to rethink this, a bit more.  I'm unhappy with how I\n> had to edit the sub-dir Makefiles to include directory names.  Sam, if\n> you happen to be reading this, feel free to help out!\n> \n> I'm almost thinking that something like:\n> \n> \tPROGS := \n> \tSCRIPTS :=\n> \tinclude x/Makefile.inc\n> \tPROGRAMS += $(addprefix x/,$PROGS)\n> \tALL_SCRIPTS += $(addprefix x/,$SCRIPTS)\n\nThat is doable for sure. But it hits you hard when you have to create\nsome special rules in a subdirectory - then you need to know in what\ndirectory you are placed. You could assing sub := x before including\nx/Makefile.inc.\n\nOn the other hand. The recursive make considered harmful is IMHO a bit\noveraggregated. See the kernel where it is used extensively. And it\nworks with no hassle. For a small project like git it should be possible\nto keep the dependencies in proper shape so there is no cross directory\nboundaries to worry about - or at least only a few.\n\n\tSam\n"},{"id":"6559","messageId":"20050729074614.GF24895@pasky.ji.cz","threadId":"1345","inReplyTo":"20050729073134.GA6507@mars.ravnborg.org","subject":"Re: [PATCH/RFC] \"Recursive Make considered harmful\"","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-29T07:46:14Z","receivedAt":"2005-07-29T07:46:14Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Jul 29, 2005 at 09:31:34AM CEST, I got a letter\nwhere Sam Ravnborg <sam@ravnborg.org> told me that...\n> > > While I do not have strong objections to make the build process\n> > > go faster, it is somewhat disturbing that the Makefile pieces\n> > > maintained in subdirectories need to name things they touch\n> > > using paths that include the subdirectory names.  I do not have\n> > > a better alternative to suggest, though...\n> \n> If the goal is to speed up the build process the only sane way is to fix\n> the dependencies. In kbuild fixdep is used to parse the .c file and it\n> locates all references to .h files (recursive) and also detects any\n> usage of CONFIG_ symbols.\n> This part should be relative straightforward to include in git.\n\nFWIW, I made tiny \"build system\" (inspired by kconfig) for smaller\nprojects I work on:\n\nhttp://pasky.or.cz/~pasky/dev/tunneler/co/Makefile\nhttp://pasky.or.cz/~pasky/dev/tunneler/co/Makefile.lib\nhttp://pasky.or.cz/~pasky/dev/tunneler/co/client/Makefile\n\nPerhaps someone might find that a nice base for further hacking. It\ngenerally appears to work pretty well in practice, although the\nautomatic dependency tracking might not be perfect.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"6571","messageId":"20050729121232.5978f5ee.tihirvon@ee.oulu.fi","threadId":"1345","inReplyTo":"20050729074614.GF24895@pasky.ji.cz","subject":"Re: [PATCH/RFC] \"Recursive Make considered harmful\"","fromName":"Timo Hirvonen","fromEmail":"tihirvon@ee.oulu.fi","sentAt":"2005-07-29T09:12:32Z","receivedAt":"2005-07-29T09:12:32Z","isPatch":true,"sender":{"key":"tihirvon@gmail.com","avatar":null},"body":"On Fri, 29 Jul 2005 09:46:14 +0200\nPetr Baudis <pasky@suse.cz> wrote:\n\n> FWIW, I made tiny \"build system\" (inspired by kconfig) for smaller\n> projects I work on:\n\nMe too! :)\n\nhttp://onion.dynserv.net/~timo/index.php?page=Projects/build\n\nIt also has configuration system written in bash.\n\n-- \nhttp://onion.dynserv.net/~timo/\n"}]}