Re: [PATCH/RFC] Recursive Make considered harmful
While I do not have strong objections to make the build process go faster, it is somewhat disturbing that the Makefile pieces maintained in subdirectories need to name things they touch using paths that include the subdirectory names. I do not have a better alternative to suggest, though... If the goal is to speed up the build process the only sane way is to fix the dependencies. In kbuild fixdep is used to parse the .c file and it locates all references to .h files (recursive) and also detects any usage of CONFIG_ symbols. This part should be relative straightforward to include in git. I think I'm going to rethink this, a bit more. I'm unhappy with how I had to edit the sub-dir Makefiles to include directory names. Sam, if you happen to be reading this, feel free to help out! I'm almost thinking that something like: PROGS := SCRIPTS := include x/Makefile.inc PROGRAMS += $(addprefix x/,$PROGS) ALL_SCRIPTS += $(addprefix x/,$SCRIPTS) That is doable for sure. But it hits you hard when you have to create some special rules in a subdirectory - then you need to know in what directory you are placed. You could assing sub := x before including x/Makefile.inc. On the other hand. The recursive make considered harmful is IMHO a bit overaggregated. See the kernel where it is used extensively. And it works with no hassle. For a small project like git it should be possible to keep the dependencies in proper shape so there is no cross directory boundaries to worry about - or at least only a few. Sam - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Recursive Make considered harmful
Dear diary, on Fri, Jul 29, 2005 at 09:31:34AM CEST, I got a letter where Sam Ravnborg [EMAIL PROTECTED] told me that... While I do not have strong objections to make the build process go faster, it is somewhat disturbing that the Makefile pieces maintained in subdirectories need to name things they touch using paths that include the subdirectory names. I do not have a better alternative to suggest, though... If the goal is to speed up the build process the only sane way is to fix the dependencies. In kbuild fixdep is used to parse the .c file and it locates all references to .h files (recursive) and also detects any usage of CONFIG_ symbols. This part should be relative straightforward to include in git. FWIW, I made tiny build system (inspired by kconfig) for smaller projects I work on: http://pasky.or.cz/~pasky/dev/tunneler/co/Makefile http://pasky.or.cz/~pasky/dev/tunneler/co/Makefile.lib http://pasky.or.cz/~pasky/dev/tunneler/co/client/Makefile Perhaps someone might find that a nice base for further hacking. It generally appears to work pretty well in practice, although the automatic dependency tracking might not be perfect. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Recursive Make considered harmful
Hi, Junio C Hamano wrote:
The Debian build is not affected because it does not produce
separate git-core and doc-git-core packages[*1*]; probably this
was the reason you did not notice this.
git-core-doc, actually.
Debian does that only if the documentation is substantial. Even then,
manpages may not be segregated into -doc.
However, I *would* segregate gitk into its own Debian package, because
it requires wish et al., which would pull a large chunk of X11 stuff,
which people may not want on their server.
Patch follows separately -- I'll have to pull it from my other mess
(which includes yet another Debian package for Cogito ;-).
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
A zealot's stones will break my bones, but gods will never hurt me.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Recursive Make considered harmful
Dear diary, on Thu, Jul 28, 2005 at 12:07:07AM CEST, I got a letter where A Large Angry SCM [EMAIL PROTECTED] told me that... Junio C Hamano wrote: While I do not have strong objections to make the build process go faster, it is somewhat disturbing that the Makefile pieces maintained in subdirectories need to name things they touch using paths that include the subdirectory names. I do not have a better alternative to suggest, though... For a project the size of Git, is there any real benefit to this change? Besides pathing issues, you also have to aware that all identifiers in the included makefile fragments will be global. I don't object to the change but I see it as trading one maintenance issue for another. I'd also argue that generally, larger files are inherently harder to maintain, and having all the targets for all the subdirectories in a single file sounds nightmarish. (OTOH, by now you probably know that I'm a keep-it-as-local-as-possible junkie.) -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Recursive Make considered harmful
Matthias Urlichs [EMAIL PROTECTED] writes: However, I *would* segregate gitk into its own Debian package, because it requires wish et al., which would pull a large chunk of X11 stuff, which people may not want on their server. While I agree gitk should not come as part of git package, this brings up a different issue. Ideally, I'd want to see gitk packaged from its repository kernel.org:/pub/scm/gitk/git.git/ Paul Mackerras maintains, not from GIT one which _will_ lag behind. We have a copy of gitk in git repository because Linus merged it as the coolest merge ever example. While I intend to keep updating from gitk repository from time to time only because I do not want to ship ancient version of it, I see a big problem down the road. What happens if someday Paul wanted to have a toplevel Makefile of his own, or if somebody sends him a patch to add debian/rules file to build a separate gitk package from its own source tree? Pulling/merging from gitk repo to update the copy git has suddenly becomes a nightmere. While I _do_ rely on gitk in my git work, and I _do_ like its simplicity (just a single file right now), my longer term preference is to drop the copy we have in git tree and treat it just like the other repository browser, qgit. Our documentation should point people at it as part of the Porcelain suite. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC] Recursive Make considered harmful
Convert build process from recurse Make to a single Make The old Makefiles in Documentation/ and tools/ still exist until we feel confident that I didn't miss anything on this conversion. Most of this patch is fixing up the main Makefile to avoid overlapping target names. Signed-off-by: Ryan Anderson [EMAIL PROTECTED] --- Documentation/Makefile.inc | 50 Makefile | 24 ++--- tools/Makefile.inc | 12 +++ 3 files changed, 78 insertions(+), 8 deletions(-) create mode 100644 Documentation/Makefile.inc create mode 100644 tools/Makefile.inc 003afd3ed1f83b4533b628182fa16c9ab0dc0467 diff --git a/Documentation/Makefile.inc b/Documentation/Makefile.inc new file mode 100644 --- /dev/null +++ b/Documentation/Makefile.inc @@ -0,0 +1,50 @@ +MAN1_TXT=$(wildcard Documentation/git-*.txt) +MAN7_TXT=Documentation/git.txt + +DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN7_TXT)) + +DOC_MAN1=$(patsubst %.txt,%.1,$(MAN1_TXT)) +DOC_MAN7=$(patsubst %.txt,%.7,$(MAN7_TXT)) + +mandir=$(prefix)/man +man1=$(mandir)/man1 +man7=$(mandir)/man7 + +# +# Please note that there is a minor bug in asciidoc. +# The version after 6.0.3 _will_ include the patch found here: +# http://marc.theaimsgroup.com/?l=gitm=111558757202243w=2 +# +# Until that version is released you may have to apply the patch +# yourself - yes, all 6 characters of it! +# + +all-doc: html man + +html: $(DOC_HTML) + + +man: man1 man7 +man1: $(DOC_MAN1) +man7: $(DOC_MAN7) + +install-doc: + $(INSTALL) -m755 -d $(dest)/$(man1) $(dest)/$(man7) + $(INSTALL) $(DOC_MAN1) $(dest)/$(man1) + $(INSTALL) $(DOC_MAN7) $(dest)/$(man7) + +# 'include' dependencies +Documentation/git-diff-%.txt: Documentation/diff-format.txt Documentation/diff-options.txt + touch $@ + +clean-doc: + rm -f Documentation/*.xml Documentation/*.html Documentation/*.1 Documentation/*.7 + +%.html : %.txt + asciidoc -b xhtml11 -d manpage $ + +%.1 %.7 : %.xml + xmlto -o Documentation/ man $ + +%.xml : %.txt + asciidoc -b docbook -d manpage $ diff --git a/Makefile b/Makefile --- a/Makefile +++ b/Makefile @@ -54,9 +54,17 @@ PROG= git-update-cache git-diff-files git-show-index git-daemon git-var git-peek-remote \ git-update-server-info git-show-rev-cache git-build-rev-cache -all: $(PROG) +include Documentation/Makefile.inc +include tools/Makefile.inc -install: $(PROG) $(SCRIPTS) +all: all-bin all-doc +all-bin: $(PROG) +#all-tools + +install: install-bin install-doc +#install-tools + +install-bin: $(PROG) $(SCRIPTS) $(INSTALL) -m755 -d $(dest)$(bin) $(INSTALL) $(PROG) $(SCRIPTS) $(dest)$(bin) @@ -204,20 +212,20 @@ rpm: dist test: all $(MAKE) -C t/ all -doc: - $(MAKE) -C Documentation all +doc: all-doc +# $(MAKE) -C Documentation all -install-tools: +install-toolsxx: $(MAKE) -C tools install -install-doc: +install-docxx: $(MAKE) -C Documentation install -clean: +clean: clean-doc clean-tools rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(LIB_FILE) rm -f git-core-*.tar.gz git-core.spec $(MAKE) -C tools/ clean - $(MAKE) -C Documentation/ clean backup: clean cd .. ; tar czvf dircache.tar.gz dir-cache + diff --git a/tools/Makefile.inc b/tools/Makefile.inc new file mode 100644 --- /dev/null +++ b/tools/Makefile.inc @@ -0,0 +1,12 @@ +# +# Make Linus git-tools +# + +PROG += $(addprefix tools/,git-mailsplit git-mailinfo) +SCRIPTS += $(addprefix tools/,git-applymbox git-applypatch) + +tools/git-%: tools/%.c + $(CC) $(CFLAGS) -o $@ $(filter %.c,$^) + +clean-tools: + rm -f tools/*.o -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Recursive Make considered harmful
Kirby C. Bohling wrote: On Wed, Jul 27, 2005 at 10:25:10AM -0400, A Large Angry SCM wrote: Ryan Anderson wrote: Convert build process from recurse Make to a single Make Please explain the rational for this. I'm new to the list, but given the subject, I'm fairly confident it's this. http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html ... He used the exact wording just about everyone dones when referring to it conceptually. It's easy to google for support and rebuttal: http://www.google.com/search?hl=enq=Recursive+Make+considered+harmfulbtnG=Google+Search Thanks for the references. A quick read of the paper and some of the rebuttals make me think that either way (recursive/non-recursive): * require about the same amount of makefile/dependency maintenance work from developers. * allow developers to be lazy in different ways with makefiles/dependencies. * achieves the same end. The non-recursive make method may have a small advantage for developers using Git for their SCM because the Git operations are also performed at the top level due to Git's design. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
