threads / patch / 43338

patchRe: [PATCH] Allow building GIT in a different directory from the source directory

Subject: Re: [PATCH] Allow building GIT in a different directory from the source directory

## tl;dr

5 messages between Dec 11, 2006 and Dec 13, 2006. Diffs are folded; open one to read it.

replies: 4people: 4as markdown or json

Han-Wen Nienhuys· Dec 11, 2006, 13:56 UTC · lore

[PATCH] Allow building GIT in a different directory from the source directory

GIT can now be built in a separate builddirectory. This is done as follows:

  mkdir build
  cd build
  $my_git_dir/configure
  make

In this case, configure creates an empty directory tree based on the source directory, and wraps Makefiles from source directory in the build directory. The rest of the functionality is delivered with the VPATH feature of Make.

To make this work the Makefile should not mention ./ explicitly in rules, but rather use $< and $^ to automatically look in the source dir too.

perl/Makefile and perl/Makefile.PL need special massaging because perl is not VPATH aware.

The documentation subdirectory has limited support for separate building, as asciidoc doesn't have a --include-path option.

 Documentation/Makefile |   36 ++++++++++++++++++++++--------------
 INSTALL                |    7 +++++++
 Makefile               |   23 ++++++++++++++---------
 config.mak.in          |    9 ++++-----
 configure.ac           |   34 ++++++++++++++++++++++++++++++++++
 generate-cmdlist.sh    |    2 +-
 perl/Makefile          |    4 ++++
 perl/Makefile.PL       |   16 +++++++++++++---
 8 files changed, 99 insertions(+), 32 deletions(-)
Show changes to 8 files +99 −32

Documentation/Makefile, INSTALL, Makefile, config.mak.in, configure.ac, generate-cmdlist.sh, perl/Makefile, perl/Makefile.PL

diff --git a/Documentation/Makefile b/Documentation/Makefile
index c00f5f6..39bcd45 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1,6 +1,6 @@
 MAN1_TXT= \
-	$(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
-		$(wildcard git-*.txt)) \
+	$(filter-out $(foreach i, $(ARTICLES) $(SP_ARTICLES), $(here-srcdir)/$(i).txt), \
+		$(wildcard $(here-srcdir)/git-*.txt)) \
 	gitk.txt
 MAN7_TXT=git.txt
 
@@ -33,8 +33,16 @@ # DESTDIR=
 
 INSTALL?=install
 
--include ../config.mak.autogen
+ifndef srcdir
+srcdir=..
+endif
+
+
+here-srcdir=$(srcdir)/Documentation
 
+ASCIIDOC_CONF=$(here-srcdir)/asciidoc.conf
+
+-include ../config.mak.autogen
 #
 # Please note that there is a minor bug in asciidoc.
 # The version after 6.0.3 _will_ include the patch found here:
@@ -63,9 +71,9 @@ install: man
 #
 # Determine "include::" file references in asciidoc files.
 #
-doc.dep : $(wildcard *.txt) build-docdep.perl
+doc.dep : $(wildcard $(here-srcdir)/*.txt) build-docdep.perl
 	rm -f $@+ $@
-	perl ./build-docdep.perl >$@+
+	perl $(lastword $^) >$@+
 	mv $@+ $@
 
 -include doc.dep
@@ -80,35 +88,35 @@ clean:
 	rm -f *.xml *.html *.1 *.7 howto-index.txt howto/*.html doc.dep README
 
 %.html : %.txt
-	asciidoc -b xhtml11 -d manpage -f asciidoc.conf $<
+	asciidoc -b xhtml11 -d manpage -f $(ASCIIDOC_CONF) $<
 
 %.1 %.7 : %.xml
-	xmlto -m callouts.xsl man $<
+	xmlto --searchpath $(here-srcdir)/  -m callouts.xsl man $<
 
 %.xml : %.txt
-	asciidoc -b docbook -d manpage -f asciidoc.conf $<
+	asciidoc -b docbook -d manpage -f $(ASCIIDOC_CONF) $<
 
 git.html: git.txt README
 
 glossary.html : glossary.txt sort_glossary.pl
 	cat $< | \
-	perl sort_glossary.pl | \
+	perl $(lastword $^) | \
 	asciidoc -b xhtml11 - > glossary.html
 
-howto-index.txt: howto-index.sh $(wildcard howto/*.txt)
+howto-index.txt: howto-index.sh $(wildcard $(here-srcdir)/howto/*.txt)
 	rm -f $@+ $@
-	sh ./howto-index.sh $(wildcard howto/*.txt) >$@+
+	sh $^ >$@+
 	mv $@+ $@
 
 $(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt
-	asciidoc -b xhtml11 $*.txt
+	asciidoc -b xhtml11 $<
 
 WEBDOC_DEST = /pub/software/scm/git/docs
 
-$(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt
+$(patsubst %.txt,%.html,$(wildcard $(here-srcdir)/howto/*.txt)): %.html : %.txt
 	rm -f $@+ $@
 	sed -e '1,/^$$/d' $< | asciidoc -b xhtml11 - >$@+
 	mv $@+ $@
 
 install-webdoc : html
-	sh ./install-webdoc.sh $(WEBDOC_DEST)
+	sh $(here-srcdir)/install-webdoc.sh $(WEBDOC_DEST)
diff --git a/INSTALL b/INSTALL
index 8f69039..b1355fa 100644
--- a/INSTALL
+++ b/INSTALL
@@ -21,6 +21,13 @@ set up install paths (via config.mak.aut
 	$ make all doc ;# as yourself
 	# make install install-doc ;# as root
 
+When using configure, git may be built in a separate directory. Use
+
+	$ mkdir builddir
+	$ cd builddir
+	$ GIT-SOURCE-DIR/configure [options]
+	$ make
+	# make install                          
 
 Issues of note:
 
diff --git a/Makefile b/Makefile
index a1861de..8e6ec62 100644
--- a/Makefile
+++ b/Makefile
@@ -97,7 +97,7 @@ # MakeMaker (e.g. using ActiveState unde
 #
 
 GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
-	@$(SHELL_PATH) ./GIT-VERSION-GEN
+	@$(SHELL_PATH) $(srcdir)/GIT-VERSION-GEN
 -include GIT-VERSION-FILE
 
 uname_S := $(shell sh -c 'uname -s 2>/dev/null || echo not')
@@ -110,15 +110,20 @@ # CFLAGS and LDFLAGS are for the users t
 
 CFLAGS = -g -O2 -Wall
 LDFLAGS =
-ALL_CFLAGS = $(CFLAGS)
+ALL_CFLAGS = $(CFLAGS) -I.
 ALL_LDFLAGS = $(LDFLAGS)
 STRIP ?= strip
 
 prefix = $(HOME)
 bindir = $(prefix)/bin
 gitexecdir = $(bindir)
-template_dir = $(prefix)/share/git-core/templates/
-# DESTDIR=
+datadir = $(prefix)/share
+GIT_datadir = $(datadir)/git-core
+template_dir = $(GIT_datadir)/templates/
+srcdir = .
+
+# this is usually set on the make command line.
+DESTDIR=
 
 # default configuration for gitweb
 GITWEB_CONFIG = gitweb_config.perl
@@ -595,8 +600,8 @@ git-merge-recur$X: git-merge-recursive$X
 $(BUILT_INS): git$X
 	rm -f $@ && ln git$X $@
 
-common-cmds.h: Documentation/git-*.txt
-	./generate-cmdlist.sh > $@+
+common-cmds.h: $(wildcard $(srcdir)/Documentation/git-*.txt)
+	$(srcdir)/generate-cmdlist.sh $(srcdir)/Documentation/ > $@+
 	mv $@+ $@
 
 $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
@@ -605,7 +610,7 @@ common-cmds.h: Documentation/git-*.txt
 	    -e 's|@@PERL@@|$(PERL_PATH_SQ)|g' \
 	    -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
 	    -e 's/@@NO_CURL@@/$(NO_CURL)/g' \
-	    $@.sh >$@+
+	    $^ >$@+
 	chmod +x $@+
 	mv $@+ $@
 
@@ -626,7 +631,7 @@ perl/perl.mak: GIT-CFLAGS
 	    -e '}' \
 	    -e 's|@@INSTLIBDIR@@|'"$$INSTLIBDIR"'|g' \
 	    -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-	    $@.perl >$@+
+	    $^ >$@+
 	chmod +x $@+
 	mv $@+ $@
 
@@ -670,7 +675,7 @@ git-instaweb: git-instaweb.sh gitweb/git
 	    -e '/@@GITWEB_CGI@@/d' \
 	    -e '/@@GITWEB_CSS@@/r gitweb/gitweb.css' \
 	    -e '/@@GITWEB_CSS@@/d' \
-	    $@.sh > $@+
+	    $< > $@+
 	chmod +x $@+
 	mv $@+ $@
 
diff --git a/config.mak.in b/config.mak.in
index 9a57840..bfbbf46 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -10,17 +10,16 @@ #INSTALL = @INSTALL@		# needs install-sh
 prefix = @prefix@
 exec_prefix = @exec_prefix@
 bindir = @bindir@
-#gitexecdir = @libexecdir@/git-core/
+mandir=@mandir@
+
+## unused, but necessary for some autoconf versions (?)
 datarootdir = @datarootdir@
-template_dir = @datadir@/git-core/templates/
 
-mandir=@mandir@
 
 srcdir = @srcdir@
-VPATH = @srcdir@
 
 export exec_prefix mandir
-export srcdir VPATH
+export srcdir 
 
 NEEDS_SSL_WITH_CRYPTO=@NEEDS_SSL_WITH_CRYPTO@
 NO_OPENSSL=@NO_OPENSSL@
diff --git a/configure.ac b/configure.ac
index 34e3478..403c410 100644
--- a/configure.ac
+++ b/configure.ac
@@ -5,6 +5,7 @@ AC_PREREQ(2.59)
 AC_INIT([git], [@@GIT_VERSION@@], [git@vger.kernel.org])
 
 AC_CONFIG_SRCDIR([git.c])
+srcdir=`cd $srcdir && pwd`
 
 config_file=config.mak.autogen
 config_append=config.mak.append
@@ -334,6 +335,39 @@ ## Output files
 AC_CONFIG_FILES(["${config_file}":"${config_in}":"${config_append}"])
 AC_OUTPUT
 
+if test "$srcdir" != "."; then
+
+  ## if we're building in another directory
+  ## we need to set it up like the sourcedir
+  for d in `cd $srcdir &&  find . -type d -print | grep -v '\.git'` ;
+  do
+    if test ! -d  $d ; then
+      echo creating $d 
+      mkdir $d
+    fi
+
+    if test -f $srcdir/$d/Makefile ; then
+
+      dnl [[]] is to keep m4 happy
+      depth=`echo $d/ | sed -e 's!^\./!!g' -e 's![[^/]]*/!../!g'`
+      echo creating $d/Makefile
+
+      if test "$depth"  = "";  then
+        INCLUDE_AUTOGEN="include config.mak.autogen" ;
+      else
+        INCLUDE_AUTOGEN="srcdir=$srcdir" 
+      fi
+ 
+      cat << EOF > $d/Makefile
+$INCLUDE_AUTOGEN
+VPATH = $srcdir/$d
+export VPATH
+include $srcdir/$d/Makefile
+EOF
+
+    fi 
+  done
+fi
 
 ## Cleanup
 rm -f "${config_append}"
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index 5450918..e744fbb 100755
--- a/generate-cmdlist.sh
+++ b/generate-cmdlist.sh
@@ -47,6 +47,6 @@ do
             x
             s/.*git-'"$cmd"' - \(.*\)/  {"'"$cmd"'", "\1"},/
 	    p
-     }' "Documentation/git-$cmd.txt"
+     }' "$1/git-$cmd.txt"
 done
 echo "};"
diff --git a/perl/Makefile b/perl/Makefile
index 099beda..ae61cf6 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -28,6 +28,10 @@ instdir_SQ = $(subst ','\'',$(prefix)/li
 	echo instlibdir: >> $@
 	echo '	echo $(instdir_SQ)' >> $@
 else
+
+PERL_SRCDIR=$(srcdir)/perl
+export PERL_SRCDIR
+
 $(makfile): Makefile.PL ../GIT-CFLAGS
 	'$(PERL_PATH_SQ)' $< PREFIX='$(prefix_SQ)'
 endif
diff --git a/perl/Makefile.PL b/perl/Makefile.PL
index 4168775..c136231 100644
--- a/perl/Makefile.PL
+++ b/perl/Makefile.PL
@@ -8,21 +8,31 @@ instlibdir:
 MAKE_FRAG
 }
 
-my %pm = ('Git.pm' => '$(INST_LIBDIR)/Git.pm');
+
+$src_prefix = "";
+if (defined ($ENV{PERL_SRCDIR})) {
+    $src_prefix = "$ENV{PERL_SRCDIR}/"
+}
+
+
+my %pm = ("$src_prefix/Git.pm" => '$(INST_LIBDIR)/Git.pm');
+
+
 
 # We come with our own bundled Error.pm. It's not in the set of default
 # Perl modules so install it if it's not available on the system yet.
 eval { require Error };
 if ($@) {
-	$pm{'private-Error.pm'} = '$(INST_LIBDIR)/Error.pm';
+	$pm{"$src_prefix/private-Error.pm"} = '$(INST_LIBDIR)/Error.pm';
 }
 
 my %extra;
 $extra{DESTDIR} = $ENV{DESTDIR} if $ENV{DESTDIR};
 
+
 WriteMakefile(
 	NAME            => 'Git',
-	VERSION_FROM    => 'Git.pm',
+	VERSION_FROM    => "$src_prefix/Git.pm",
 	PM		=> \%pm,
 	MAKEFILE	=> 'perl.mak',
 	%extra
 
 
-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
Junio C Hamano· Dec 12, 2006, 09:03 UTC · re: Han-Wen Nienhuys · lore
Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
Show 7 quoted lines
> GIT can now be built in a separate builddirectory. This is done as
> follows:
>
>   mkdir build
>   cd build
>   $my_git_dir/configure
>   make

Somehow making this depend on the use of configure feels wrong, since we tried to keep that config.mak.gen built by configure strictly optional. In other words, I think the result of your patch should be buildable with or without ./configure in a separate directory if we are going to do this.

Care to explain why it is too cumbersome to handle without ./configure magic?

Han-Wen Nienhuys· Dec 12, 2006, 11:50 UTC · re: Junio C Hamano · lore
Junio C Hamano escreveu:
Show 18 quoted lines
> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> 
>> GIT can now be built in a separate builddirectory. This is done as
>> follows:
>>
>>   mkdir build
>>   cd build
>>   $my_git_dir/configure
>>   make
> 
> Somehow making this depend on the use of configure feels wrong,
> since we tried to keep that config.mak.gen built by configure
> strictly optional.  In other words, I think the result of your
> patch should be buildable with or without ./configure in a
> separate directory if we are going to do this.
> 
> Care to explain why it is too cumbersome to handle without
> ./configure magic?

I already tried to explain in a previous thread on the list. See

  http://article.gmane.org/gmane.comp.version-control.git/33487
  
you can still build git in the same directory as source 
without using autoconf, and plain make.
If you insist, I can create a separate
  setup-builddir.sh

to setup the build directory; according to the principle of least surprise, it should happen in the configure script though.

I still don't understand the problem with autoconf; there are already plenty of baroque shell scripts in GIT. I hate writing m4 macros as well, but that's not a problem for GIT users (ie. people who compile GIT).

For them, 
  ./configure ; make ; make check ; make install
is actually the standard way to compile stuff.
Johannes Schindelin· Dec 12, 2006, 18:55 UTC · re: Han-Wen Nienhuys · lore
Hi,
On Tue, 12 Dec 2006, Han-Wen Nienhuys wrote:
> I still don't understand the problem with autoconf; there are already 
> plenty of baroque shell scripts in GIT.  I hate writing m4 macros as 
> well, but that's not a problem for GIT users (ie. people who compile 
> GIT).

That, together with the complexity of GIT_EXEC_DIR and path mangling problems, makes me take every opportunity to suggest we should build in most if not all of Git into the "git wrapper".

Granted, without completion scripts, the "git-" convention was nice.

Granted, with bash, Perl and even Python, you can rapidly prototype your thoughts (even if I often miss the power of C there).

But in the end, I'd say it makes lots of sense to have everything in one executable.

Ciao, Dscho

Andreas Ericsson· Dec 13, 2006, 09:28 UTC · re: Johannes Schindelin · lore
Johannes Schindelin wrote:
Show 18 quoted lines
> Hi,
> 
> On Tue, 12 Dec 2006, Han-Wen Nienhuys wrote:
> 
>> I still don't understand the problem with autoconf; there are already 
>> plenty of baroque shell scripts in GIT.  I hate writing m4 macros as 
>> well, but that's not a problem for GIT users (ie. people who compile 
>> GIT).
> 
> That, together with the complexity of GIT_EXEC_DIR and path mangling 
> problems, makes me take every opportunity to suggest we should build in 
> most if not all of Git into the "git wrapper".
> 
> Granted, without completion scripts, the "git-" convention was nice.
> 
> Granted, with bash, Perl and even Python, you can rapidly prototype your 
> thoughts (even if I often miss the power of C there).
> 

We could still allow that by simply not removing the "run this external program" code from the git wrapper even if we make all default commands built-ins. Pluggable git, just as it is today, and when something turns out to be useful, feature-complete and stable enough "someone" will hopefully hop in to make it a built-in.

> But in the end, I'd say it makes lots of sense to have everything in one 
> executable.
> 

Yup. Not least for portability issues. The lack of a native windows client has already made us lose at least one major "customer", and afaiu it was *only* the lack of a native windows client that caused this, so obviously it's a big issue for big cross-platform projects.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se

← back to recent threads