Han-Wen Nienhuys [off-list ref] 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?
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
Junio C Hamano escreveu:
Han-Wen Nienhuys [off-list ref] writes:
quoted
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 wrote:
Hi,
On Tue, 12 Dec 2006, Han-Wen Nienhuys wrote:
quoted
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