autoconf: Use autoconf to write installation directories to config.mak.autogen
Subsystems (2)
PATCH 1/1 autoconf: Use autoconf to write installation directories to config.mak.autogen
This is beginning of patch series introducing installation configuration using autoconf (and no other autotools) to git. The idea is to generate config.mak.autogen using ./configure (generated from configure.ac by running autoconf) from config.mak.in, so one can use autoconf as an _alternative_ to ordinary Makefile, and creating one's own config.mak. Local settings in config.mak override generated settings in config.mak.autogen
This patch includes minimal configure.ac and config.mak.in, so one can set installation directories using autoconf generated ./configure script e.g. ./configure --prefix=/usr
---
This patch is to be applied on top of 'next', because to work as intended (especially for --mandir=<path> option to ./configure) it needs
Allow INSTALL, bindir, mandir to be set in main Makefile e14421b9aa85f11853a0dacae09498515daab7b8
patch (commit) to be present.
For now the following options do actually something:
$ ./configure
--prefix=<prefix> # [/usr/local]
--exec_prefix=<prefix> # [PREFIX]
--bindir=<bindir> # [EPREFIX/bin]
--datadir=<datadir> # [PREFIX/share]
--mandir=<mandir> # [PREFIX/man]$ ./configure --help # hardcoded version 1.4.1
QUESTION: how to make autoconf _generate_ correct version string?
Next patch will show how this infrastructure can be used.
.gitignore | 6 ++++++ INSTALL | 9 +++++++++ Makefile | 1 + config.mak.in | 18 ++++++++++++++++++ configure.ac | 14 ++++++++++++++ 5 files changed, 48 insertions(+), 0 deletions(-)
.gitignore +6 -0
@@ -136,4 +136,10 @@ git-core.spec *.[ao] *.py[co] config.mak +autom4te.cache +config.log +config.status +config.mak.in +config.mak.autogen +configure git-blame
INSTALL +9 -0
@@ -13,6 +13,15 @@ that uses $prefix, the built results hav which are derived from $prefix, so "make all; make prefix=/usr install" would not work. +Alternatively you can use autoconf generated ./configure script to +set up install paths (via config.mak.autogen), so you can write instead + + $ autoconf ;# as yourself if ./configure doesn't exist yet + $ ./configure --prefix=/usr ;# as yourself + $ make all doc ;# as yourself + # make install install-doc ;# as root + + Issues of note: - git normally installs a helper script wrapper called "git", which
Makefile +1 -0
@@ -333,6 +333,7 @@ ifneq (,$(findstring arm,$(uname_M))) ARM_SHA1 = YesPlease endif +-include config.mak.autogen -include config.mak ifdef WITH_OWN_SUBPROCESS_PY
config.mak.in new file +18 -0
@@ -0,0 +1,18 @@ +# git Makefile configuration, included in main Makefile +# @configure_input@ + +prefix = @prefix@ +exec_prefix = @exec_prefix@ +bindir = @bindir@ +#gitexecdir = @libexecdir@/git-core/ +template_dir = @datadir@/git-core/templates/ +GIT_PYTHON_DIR = @datadir@/git-core/python + +mandir=@mandir@ + +srcdir = @srcdir@ +VPATH = @srcdir@ + +export exec_prefix mandir +export srcdir VPATH +
configure.ac new file +14 -0
@@ -0,0 +1,14 @@ +# -*- Autoconf -*- +# Process this file with autoconf to produce a configure script. + +AC_PREREQ(2.59) +AC_INIT([git], [1.4.1], [[email protected]]) + +AC_CONFIG_SRCDIR([git.c]) + +config_file=config.mak.autogen +config_in=config.mak.in + +# Output files +AC_CONFIG_FILES(["${config_file}":"${config_in}"]) +AC_OUTPUT
Signature · 1 line
1.4.0
PATCH 1/1 autoconf: Use ./configure script in git *.spec file
--- git.spec.in | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
git.spec.in +2 -2
@@ -74,13 +74,13 @@ Git revision tree visualiser ('gitk') %setup -q %build +%configure make %{_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" WITH_OWN_SUBPROCESS_PY=YesPlease \ - prefix=%{_prefix} all %{!?_without_docs: doc} + all %{!?_without_docs: doc} %install rm -rf $RPM_BUILD_ROOT make %{_smp_mflags} DESTDIR=$RPM_BUILD_ROOT WITH_OWN_SUBPROCESS_PY=YesPlease \ - prefix=%{_prefix} mandir=%{_mandir} \ install %{!?_without_docs: install-doc} (find $RPM_BUILD_ROOT%{_bindir} -type f | grep -vE "arch|svn|cvs|email|gitk" | sed -e s@^$RPM_BUILD_ROOT@@) > bin-man-doc-files
Signature · 1 line
1.4.0
Re: [PATCH 2] autoconf: Use ./configure script in git *.spec file
I thought this stuff was "opt-in", but make rpm now requires autoconf?
Re: [PATCH 2] autoconf: Use ./configure script in git *.spec file
Quoted 2 lines · Junio C Hamano
I thought this stuff was "opt-in", but make rpm now requires autoconf?
Ooops. No, git RPM wouldn't need autoconf, neither building git from *.spec file or SRPM. But rpm targed will need autoconf run, and configure script packed in tar file (and I think that having configure script in distribution tar files will be good idea... but perhaps optionally under NO_AUTOCONF or USE_AUTOCONF).
And I of course forgot about that. So that is only half of a patch...
Besides that patch was meant as example of using autoconf. Automatic tool (rpmbuild) using automatic tool (./configure script).
P.S. we could distribute ./configure script like we distribute preformatted documentation, in separate 'configure' branch.
Signature · 3 lines
Jakub Narebski Warsaw, Poland ShadeHawk on #git
Re: [PATCH 2] autoconf: Use ./configure script in git *.spec file
Quoted 7 lines · Jakub Narebski
Quoted 2 lines · Junio C Hamano
I thought this stuff was "opt-in", but make rpm now requires autoconf?
Ooops. No, git RPM wouldn't need autoconf, neither building git from *.spec file or SRPM.
I had an impression that your spec.in change made it required.
It is still somewhat dubious to me if we can keep this "opt-in". I noticed that it at least lacks a few extra commands to "clean" target of the main Makefile, and adding them by itself is not so bad, but who knows what else it would bring in when the series finishes. I would not be surprised if we start touching *.c and *.h files with new autoconf-compatible "#ifdef HAVE_XXX" and at that point I will say "I told you so".
I am not opposed to giving an alternative, semi-automated way to edit config.mak to the users, and if that is our goal, we should ship the configure script in the source tarball at least, and probably we should have the configure script in the revisions as well. Using autoconf is not the goal here -- giving ./configure as an alternative way to manage config.mak is.
But if we have autoconf scripts _and_ configure script in revisions, we are talking about version controlling generated stuff, and I'd like to avoid that at all cost.
Maybe an alternative is to just add configure script in the source tree _without_ adding any of the autoconf scripts to the git repository. The users can choose to use that script to manage config.mak but do not have to. And I do not mind getting occasional updates to the configure script in the source tree, and I do not care if you build it by hand or use autoconf to generate it, as long as the configure script is readable, debuggable and maintainable.
The source to generate that configure script might be autoconf scripts and you would want to version control that. That is fine but I think that would be a separate project of yours, and you may call that the git-build-config project. And I do not mind hosting that somewhere under contrib/ area in the git repository in order to give it wider exposure.
That would end up in the same situation as having the source and generated files under the version control, but I think at the philosophical level the two are vastly different, in that the things under contrib/ are not part of git.git but are there only for convenience. I will not be the one who is responsible to run autoconf in there every time we make changes to the system and propagate the changes to the main configure script. The configure script generated by the end user in contrib/autoconf may not match the toplevel configure script (the end user may have different version of autoconf, for example) but that is not a bug, as long as the toplevel configure script, which might be output by an older version of autoconf, works correctly.
The above assumes that the configure script generated by your autoconf script is readable and maintainable at all. Otherwise it would not make any sense to have configure under version control.
contrib/ status
Quoted 3 lines · Junio C Hamano
... the
things under contrib/ are not part of git.git but are there only for convenience....
This reminds me of something quite different. I am getting an impression that enough people have been helped by git-svn and it might be a good idea to have it outside contrib/ area.
OTOH I haven't seen much interest in contrib/colordiff, now Johannes's built-in "diff --color" is in. So if people do not mind, I'd like to drop it.
Re: contrib/ status
Quoted 9 lines · Junio C Hamano
Quoted 3 lines · Junio C Hamano
... the
things under contrib/ are not part of git.git but are there only for convenience....This reminds me of something quite different. I am getting an impression that enough people have been helped by git-svn and it might be a good idea to have it outside contrib/ area.
That would be great. IMHO, it puts git in a position to supplant centralized SVN usage one developer at a time, making it easier to make a gradual transition to git. Of course, there's also svk in a similar position...
Signature · 1 line
Eric Wong
Re: contrib/ status
Quoted 7 lines · Eric Wong
Quoted 6 lines · Junio C Hamano
Quoted 3 lines · Junio C Hamano
... the
things under contrib/ are not part of git.git but are there only for convenience....
Quoted 8 lines
Quoted 3 lines
This reminds me of something quite different. I am getting an impression that enough people have been helped by git-svn and it might be a good idea to have it outside contrib/ area.
That would be great. IMHO, it puts git in a position to supplant centralized SVN usage one developer at a time, making it easier to make a gradual transition to git. Of course, there's also svk in a similar position...
OK, then let's give a few days (it's a long weekend extendeding into July 4th in the US) to let others from the list chime in, and then please help me migrate your test scripts and Makefile pieces into the toplevel project.
Re: contrib/ status
Quoted 18 lines · Junio C Hamano
Quoted 7 lines · Eric Wong
Quoted 6 lines · Junio C Hamano
Quoted 3 lines · Junio C Hamano
... the
things under contrib/ are not part of git.git but are there only for convenience....Quoted 8 lines
Quoted 3 lines
This reminds me of something quite different. I am getting an impression that enough people have been helped by git-svn and it might be a good idea to have it outside contrib/ area.
That would be great. IMHO, it puts git in a position to supplant centralized SVN usage one developer at a time, making it easier to make a gradual transition to git. Of course, there's also svk in a similar position...
Quoted 4 lines
OK, then let's give a few days (it's a long weekend extendeding into July 4th in the US) to let others from the list chime in, and then please help me migrate your test scripts and
Makefilepieces into the toplevel project.
Ok, I'll have a patch ready by then. I'm not sure which number family I should take for the tests, 8xxx and 9xxx don't have any rules for their use, but the [89]0xx area seems taken. Would naming them 91xx be good?
Also, the tests can be extremely slow since they rely on svn, so there will be a way to skip the tests if users are not interested.
Signature · 1 line
Eric Wong
[RFC/PATCH] git-svn: migrate out of contrib
Allow NO_SVN_TESTS to be defined to skip git-svn tests. These tests are time-consuming due to SVN being slow, and even more so if SVN Perl libraries are not available.
---
.gitignore | 1
{contrib/git-svn => Documentation}/git-svn.txt | 0
Makefile | 6 ++-
contrib/git-svn/.gitignore | 4 --
contrib/git-svn/Makefile | 44 --------------------
contrib/git-svn/git-svn.perl => git-svn.perl | 2 -
t/Makefile | 10 +++++
{contrib/git-svn/t => t}/lib-git-svn.sh | 18 ++++----
.../t9100-git-svn-basic.sh | 4 ++
.../t9101-git-svn-props.sh | 0
.../t9102-git-svn-deep-rmdir.sh | 0
.../t9103-git-svn-graft-branches.sh | 0
.../t9104-git-svn-follow-parent.sh | 0
.../t9105-git-svn-commit-diff.sh | 0
14 files changed, 28 insertions(+), 61 deletions(-).gitignore +1 -0
@@ -106,6 +106,7 @@ git-ssh-push git-ssh-upload git-status git-stripspace +git-svn git-svnimport git-symbolic-ref git-tag
Documentation/git-svn.txt renamed from contrib/git-svn/git-svn.txt +0 -0
Makefile +5 -1
@@ -33,6 +33,10 @@ # # Define NO_SYMLINK_HEAD if you never want .git/HEAD to be a symbolic link. # Enable it on Windows. By default, symrefs are still used. # +# Define NO_SVN_TESTS if you want to skip time-consuming SVN interopability +# tests. These tests take up a significant amount of the total test time +# but are not needed unless you plan to talk to SVN repos. +# # Define PPC_SHA1 environment variable when running make to make use of # a bundled SHA1 routine optimized for PowerPC. #
@@ -134,7 +138,7 @@ SCRIPT_PERL = \ git-shortlog.perl git-rerere.perl \ git-annotate.perl git-cvsserver.perl \ git-svnimport.perl git-mv.perl git-cvsexportcommit.perl \ - git-send-email.perl + git-send-email.perl git-svn.perl SCRIPT_PYTHON = \ git-merge-recursive.py
contrib/git-svn/.gitignore deleted +0 -4
@@ -1,4 +0,0 @@ -git-svn -git-svn.xml -git-svn.html -git-svn.1
contrib/git-svn/Makefile deleted +0 -44
44 lines not on this page · raw message
git-svn.perl renamed from contrib/git-svn/git-svn.perl +1 -1
@@ -8,7 +8,7 @@ use vars qw/ $AUTHOR $VERSION $GIT_SVN_INDEX $GIT_SVN $GIT_DIR $GIT_SVN_DIR $REVDB/; $AUTHOR = 'Eric Wong <[email protected]>'; -$VERSION = '1.1.1-broken'; +$VERSION = '@@GIT_VERSION@@'; use Cwd qw/abs_path/; $GIT_DIR = abs_path($ENV{GIT_DIR} || '.git');
t/Makefile +10 -0
@@ -11,6 +11,7 @@ # Shell quote; SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH)) T = $(wildcard t[0-9][0-9][0-9][0-9]-*.sh) +TSVN = $(wildcard t91[0-9][0-9]-*.sh) ifdef NO_PYTHON GIT_TEST_OPTS += --no-python
@@ -24,6 +25,15 @@ all: $(T) clean clean: rm -fr trash +# we can test NO_OPTIMIZE_COMMITS independently of LC_ALL +full-svn-test: + $(MAKE) $(TSVN) GIT_SVN_NO_LIB=1 GIT_SVN_NO_OPTIMIZE_COMMITS=1 LC_ALL=C + $(MAKE) $(TSVN) GIT_SVN_NO_LIB=0 GIT_SVN_NO_OPTIMIZE_COMMITS=1 LC_ALL=C + $(MAKE) $(TSVN) GIT_SVN_NO_LIB=1 GIT_SVN_NO_OPTIMIZE_COMMITS=0 \ + LC_ALL=en_US.UTF-8 + $(MAKE) $(TSVN) GIT_SVN_NO_LIB=0 GIT_SVN_NO_OPTIMIZE_COMMITS=0 \ + LC_ALL=en_US.UTF-8 + .PHONY: $(T) clean .NOTPARALLEL:
t/lib-git-svn.sh renamed from contrib/git-svn/t/lib-git-svn.sh +8 -10
@@ -1,14 +1,12 @@ -PATH=$PWD/../:$PATH -if test -d ../../../t +. ./test-lib.sh + +if test -n "$NO_SVN_TESTS" then - cd ../../../t -else - echo "Must be run in contrib/git-svn/t" >&2 - exit 1 + test_expect_success 'skipping git-svn tests, NO_SVN_TESTS defined' : + test_done + exit fi -. ./test-lib.sh - GIT_DIR=$PWD/.git GIT_SVN_DIR=$GIT_DIR/svn/git-svn SVN_TREE=$GIT_SVN_DIR/svn-tree
@@ -16,7 +14,7 @@ SVN_TREE=$GIT_SVN_DIR/svn-tree svnadmin >/dev/null 2>&1 if test $? != 1 then - test_expect_success 'skipping contrib/git-svn test' : + test_expect_success 'skipping git-svn tests, svnadmin not found' : test_done exit fi
@@ -24,7 +22,7 @@ fi svn >/dev/null 2>&1 if test $? != 1 then - test_expect_success 'skipping contrib/git-svn test' : + test_expect_success 'skipping git-svn tests, svn not found' : test_done exit fi
t/t9100-git-svn-basic.sh renamed from contrib/git-svn/t/t0000-contrib-git-svn.sh +3 -1
@@ -3,7 +3,7 @@ # # Copyright (c) 2006 Eric Wong # -test_description='git-svn tests' +test_description='git-svn basic tests' GIT_SVN_LC_ALL=$LC_ALL case "$LC_ALL" in
@@ -17,6 +17,8 @@ esac . ./lib-git-svn.sh +echo 'define NO_SVN_TESTS to skip git-svn tests' + mkdir import cd import
t/t9101-git-svn-props.sh renamed from contrib/git-svn/t/t0001-contrib-git-svn-props.sh +0 -0
t/t9102-git-svn-deep-rmdir.sh renamed from contrib/git-svn/t/t0002-deep-rmdir.sh +0 -0
t/t9103-git-svn-graft-branches.sh renamed from contrib/git-svn/t/t0003-graft-branches.sh +0 -0
t/t9104-git-svn-follow-parent.sh renamed from contrib/git-svn/t/t0004-follow-parent.sh +0 -0
t/t9105-git-svn-commit-diff.sh renamed from contrib/git-svn/t/t0005-commit-diff.sh +0 -0
Signature · 1 line
1.4.1.ge255
Re: [RFC/PATCH] git-svn: migrate out of contrib
Overall it looks good.
9104 and 9105 fail when GIT_SVN_NO_LIB is unset and the libsvn-*-perl is not available. Maybe check this just like you check and omit tests when svn or svnadmin is unavailable?
PATCH 1/1 git-svn: migrate out of contrib
Allow NO_SVN_TESTS to be defined to skip git-svn tests. These tests are time-consuming due to SVN being slow, and even more so if SVN Perl libraries are not available.
Also added a check for SVN::Core so test 910[45] don't fail if the user doesn't have those installed, thanks to Junio for noticing this.
---
Quoted 5 lines · Junio C Hamano
Overall it looks good.
9104 and 9105 fail when
GIT_SVN_NO_LIBis unset and the libsvn-*-perl is not available. Maybe check this just like you check and omit tests when svn or svnadmin is unavailable?
Done. While I was at it, I changed the test != to test -eq and brought the similarity below the threshold, which may make me want to expand on another patch...
.gitignore | 1
{contrib/git-svn => Documentation}/git-svn.txt | 0
Makefile | 6 ++-
contrib/git-svn/.gitignore | 4 --
contrib/git-svn/Makefile | 44 --------------------
contrib/git-svn/git-svn.perl => git-svn.perl | 2 -
t/Makefile | 10 +++++
{contrib/git-svn/t => t}/lib-git-svn.sh | 29 ++++++++-----
.../t9100-git-svn-basic.sh | 4 ++
.../t9101-git-svn-props.sh | 0
.../t9102-git-svn-deep-rmdir.sh | 0
.../t9103-git-svn-graft-branches.sh | 0
.../t9104-git-svn-follow-parent.sh | 0
.../t9105-git-svn-commit-diff.sh | 0
14 files changed, 37 insertions(+), 63 deletions(-).gitignore +1 -0
@@ -107,6 +107,7 @@ git-ssh-push git-ssh-upload git-status git-stripspace +git-svn git-svnimport git-symbolic-ref git-tag
Documentation/git-svn.txt renamed from contrib/git-svn/git-svn.txt +0 -0
Makefile +5 -1
@@ -33,6 +33,10 @@ # # Define NO_SYMLINK_HEAD if you never want .git/HEAD to be a symbolic link. # Enable it on Windows. By default, symrefs are still used. # +# Define NO_SVN_TESTS if you want to skip time-consuming SVN interopability +# tests. These tests take up a significant amount of the total test time +# but are not needed unless you plan to talk to SVN repos. +# # Define PPC_SHA1 environment variable when running make to make use of # a bundled SHA1 routine optimized for PowerPC. #
@@ -134,7 +138,7 @@ SCRIPT_PERL = \ git-shortlog.perl git-rerere.perl \ git-annotate.perl git-cvsserver.perl \ git-svnimport.perl git-mv.perl git-cvsexportcommit.perl \ - git-send-email.perl + git-send-email.perl git-svn.perl SCRIPT_PYTHON = \ git-merge-recursive.py
contrib/git-svn/.gitignore deleted +0 -4
@@ -1,4 +0,0 @@ -git-svn -git-svn.xml -git-svn.html -git-svn.1
contrib/git-svn/Makefile deleted +0 -44
44 lines not on this page · raw message
git-svn.perl renamed from contrib/git-svn/git-svn.perl +1 -1
@@ -8,7 +8,7 @@ use vars qw/ $AUTHOR $VERSION $GIT_SVN_INDEX $GIT_SVN $GIT_DIR $GIT_SVN_DIR $REVDB/; $AUTHOR = 'Eric Wong <[email protected]>'; -$VERSION = '1.1.1-broken'; +$VERSION = '@@GIT_VERSION@@'; use Cwd qw/abs_path/; $GIT_DIR = abs_path($ENV{GIT_DIR} || '.git');
t/Makefile +10 -0
@@ -11,6 +11,7 @@ # Shell quote; SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH)) T = $(wildcard t[0-9][0-9][0-9][0-9]-*.sh) +TSVN = $(wildcard t91[0-9][0-9]-*.sh) ifdef NO_PYTHON GIT_TEST_OPTS += --no-python
@@ -24,6 +25,15 @@ all: $(T) clean clean: rm -fr trash +# we can test NO_OPTIMIZE_COMMITS independently of LC_ALL +full-svn-test: + $(MAKE) $(TSVN) GIT_SVN_NO_LIB=1 GIT_SVN_NO_OPTIMIZE_COMMITS=1 LC_ALL=C + $(MAKE) $(TSVN) GIT_SVN_NO_LIB=0 GIT_SVN_NO_OPTIMIZE_COMMITS=1 LC_ALL=C + $(MAKE) $(TSVN) GIT_SVN_NO_LIB=1 GIT_SVN_NO_OPTIMIZE_COMMITS=0 \ + LC_ALL=en_US.UTF-8 + $(MAKE) $(TSVN) GIT_SVN_NO_LIB=0 GIT_SVN_NO_OPTIMIZE_COMMITS=0 \ + LC_ALL=en_US.UTF-8 + .PHONY: $(T) clean .NOTPARALLEL:
t/lib-git-svn.sh renamed from contrib/git-svn/t/lib-git-svn.sh +17 -12
@@ -1,30 +1,35 @@ -PATH=$PWD/../:$PATH -if test -d ../../../t +. ./test-lib.sh + +if test -n "$NO_SVN_TESTS" then - cd ../../../t -else - echo "Must be run in contrib/git-svn/t" >&2 - exit 1 + test_expect_success 'skipping git-svn tests, NO_SVN_TESTS defined' : + test_done + exit fi -. ./test-lib.sh - GIT_DIR=$PWD/.git GIT_SVN_DIR=$GIT_DIR/svn/git-svn SVN_TREE=$GIT_SVN_DIR/svn-tree +perl -e 'use SVN::Core' >/dev/null 2>&1 +if test $? -ne 0 +then + echo 'Perl SVN libraries not found, tests requiring those will be skipped' + GIT_SVN_NO_LIB=1 +fi + svnadmin >/dev/null 2>&1 -if test $? != 1 +if test $? -ne 1 then - test_expect_success 'skipping contrib/git-svn test' : + test_expect_success 'skipping git-svn tests, svnadmin not found' : test_done exit fi svn >/dev/null 2>&1 -if test $? != 1 +if test $? -ne 1 then - test_expect_success 'skipping contrib/git-svn test' : + test_expect_success 'skipping git-svn tests, svn not found' : test_done exit fi
t/t9100-git-svn-basic.sh renamed from contrib/git-svn/t/t0000-contrib-git-svn.sh +3 -1
@@ -3,7 +3,7 @@ # # Copyright (c) 2006 Eric Wong # -test_description='git-svn tests' +test_description='git-svn basic tests' GIT_SVN_LC_ALL=$LC_ALL case "$LC_ALL" in
@@ -17,6 +17,8 @@ esac . ./lib-git-svn.sh +echo 'define NO_SVN_TESTS to skip git-svn tests' + mkdir import cd import
t/t9101-git-svn-props.sh renamed from contrib/git-svn/t/t0001-contrib-git-svn-props.sh +0 -0
t/t9102-git-svn-deep-rmdir.sh renamed from contrib/git-svn/t/t0002-deep-rmdir.sh +0 -0
t/t9103-git-svn-graft-branches.sh renamed from contrib/git-svn/t/t0003-graft-branches.sh +0 -0
t/t9104-git-svn-follow-parent.sh renamed from contrib/git-svn/t/t0004-follow-parent.sh +0 -0
t/t9105-git-svn-commit-diff.sh renamed from contrib/git-svn/t/t0005-commit-diff.sh +0 -0
Signature · 1 line
1.4.1.g3dc65
Re: contrib/ status
In reply to Junio C HamanoQuoted 3 lines · Junio C Hamano
OTOH I haven't seen much interest in contrib/colordiff, now Johannes's built-in "diff --color" is in. So if people do not mind, I'd like to drop it.
Since when, and is it documented?
Signature · 3 lines
Jakub Narebski Warsaw, Poland ShadeHawk on #git
Re: contrib/ status
Hi,
Quoted 7 lines · Jakub Narebski
Quoted 3 lines · Junio C Hamano
OTOH I haven't seen much interest in contrib/colordiff, now Johannes's built-in "diff --color" is in. So if people do not mind, I'd like to drop it.
Since when, and is it documented?
To your first question:
commit cd112cef999c59a7ca2a96c37b197d303a355924 Author: Johannes Schindelin <[email protected]> Date: Tue Jun 13 18:45:44 2006 +0200 diff options: add --color
To the second:
No.
;-) It should be in diff-options.txt, but then you would have to document the config variables to change the color, too, so I'll leave that task to somebody else and go back to work...
Ciao,
Dscho
Re: [PATCH 2] autoconf: Use ./configure script in git *.spec file
In reply to Junio C HamanoAs I see it, we have the following options with respect to autoconf related files and use of ./configure script
1. Use autoconf and ./configure script generated by it as optional way to configure installation process. Have configure.ac and config.mak.in in main directory of git.git repository. Do not use ./configure script in git.spec.in, i.e. do not apply this patch... perhaps put _patch_ in the contrib/. Leave changes to *.spec file to distributions, documenting it somewhere.
2. Use autoconf and ./configure script generated by it as optional way to configure installation process _and_ in git.spec.in, i.e. in the RPM building. Ship generated 'configure' script with distribution (source) tarball or make patch creating 'configure' script and use it instead in git.spec.in (avoids shipping 'configure' in source tarball). This has the consequence that autoconf would be build dependence for creating RPM at least. Perhaps we can have automatically build configure script in separate branch, similarly to 'man' and 'html branches of git.git.
3. Write our own ./configure script, put it under version control, and put autoconf related files in contrib/ as an alternative. Advantages: we can customize it to git needs and git build process conventions. Disadvantages:
duplication of work put into autoconf to make generated ./configure script portable (which is also the case why atoconf generated shel script 'configure' is not very readable, and probably should be not under version control; html and man documentation aren't either). Use %configure in git.spec.in file. Plan for the future?
I am partially to [*1*], if just because I wouldn't need to take care autoconf in git. [*2*] has disadvantage in that generated ./configure needs to be put in main directory to work, either by hand (which complicates using this way of building and installing git) or by script (which violates unsaid rule that contrib/ doesn't interfere in top directory). [*3*] would be probably the best, but it is additional work, duplication of autoconf efforts, and need someone (not me) well versed in git compiling woes _and_ shell script portability.
Signature · 2 lines
Jakub Narębski ShadeHawk on #git
Re: [PATCH 2] autoconf: Use ./configure script in git *.spec file
Quoted 4 lines · Jakub Narebski
As I see it, we have the following options with respect to autoconf related files and use of ./configure script
Quoted 9 lines
1. Use autoconf and ./configure script generated by it as optional way to configure installation process. Have configure.ac and config.mak.in in main directory of git.git repository. Do not use ./configure script in git.spec.in, i.e. do not apply this patch... perhaps put _patch_ in the contrib/. Leave changes to *.spec file to distributions, documenting it somewhere.
..
I am partially to [*1*], if just because I wouldn't need to take care autoconf in git.
I do not understand this "I wouldn't need to take care autoconf in git" part. Sorry.
Re: [PATCH 2] autoconf: Use ./configure script in git *.spec file
Quoted 3 lines · Junio C Hamano
Quoted 1 line · Jakub Narebski
As I see it, we have the following options with respect to autoconf
related
Quoted 5 lines
Quoted 5 lines
files and use of ./configure script
1. Use autoconf and ./configure script generated by it as optional way to configure installation process. Have configure.ac and config.mak.in in
main
Quoted 10 lines
Quoted 7 lines
directory of git.git repository. Do not use ./configure script in git.spec.in, i.e. do not apply this patch... perhaps put _patch_ in the contrib/. Leave changes to *.spec file to distributions, documenting it somewhere.
..
I am partially to [*1*], if just because I wouldn't need to take care autoconf in git.I do not understand this "I wouldn't need to take care autoconf in git" part. Sorry.
Gah. It should be: "if just because there would be no need to have someone to take care that ./configure is up-to-date with respect to changes in autoconf files". Sorry for the noise.
Signature · 3 lines
Jakub Narebski Warsaw, Poland ShadeHawk on #git
PATCH 1/1 autoconf: Use %configure in git.spec, autoconf dependency only in rpm target
In reply to Jakub NarebskiThis is __Proof of Concept__ patch, which makes use of predefined %configure rpm macro to define install dirs, using autoconf generated ./configure script.
This patch introduces dependency on autoconf _only_ for rpm target during build process.
---
Probably there is more portable way of ignoring diff exit status than using '|| true', and probably better way to generate
"file creation"/"new file" patch from a working directory (only) file (perhaps using git-diff too).
Sidenote 1: current git.spec.in doesn't allow building RPMS from a dirty version:
error: line 3: Illegal char '-' in version: Version: 1.4.1.g1c7c-dirty
Is it intentional?
Sidenote 2: building rpm currently does compilation _twice_, once to generate git-tar-tree, and once in the rpm build (in BuildRoot).
Makefile | 3 +++ git.spec.in | 6 ++++-- 2 files changed, 7 insertions(+), 2 deletions(-)
Makefile +3 -0
@@ -721,6 +722,9 @@ dist: git.spec git-tar-tree gzip -f -9 $(GIT_TARNAME).tar rpm: dist + autoconf + diff -Nu /dev/null configure > git-add-autoconf-configure.patch || true + gzip -f -9 git-add-autoconf-configure.patch $(RPMBUILD) -ta $(GIT_TARNAME).tar.gz htmldocs = git-htmldocs-$(GIT_VERSION)
git.spec.in +4 -2
@@ -7,6 +7,7 @@ License: GPL Group: Development/Tools URL: http://kernel.org/pub/software/scm/git/ Source: http://kernel.org/pub/software/scm/git/%{name}-%{version}.tar.gz +Patch0: git-add-autoconf-configure.patch.gz BuildRequires: zlib-devel >= 1.2, openssl-devel, curl-devel, expat-devel %{!?_without_docs:, xmlto, asciidoc > 6.0.3} BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) Requires: git-core, git-svn, git-cvs, git-arch, git-email, gitk
@@ -72,15 +73,16 @@ Git revision tree visualiser ('gitk') %prep %setup -q +%patch0 -p0 %build +%configure make %{_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" WITH_OWN_SUBPROCESS_PY=YesPlease \ - prefix=%{_prefix} all %{!?_without_docs: doc} + all %{!?_without_docs: doc} %install rm -rf $RPM_BUILD_ROOT make %{_smp_mflags} DESTDIR=$RPM_BUILD_ROOT WITH_OWN_SUBPROCESS_PY=YesPlease \ - prefix=%{_prefix} mandir=%{_mandir} \ install %{!?_without_docs: install-doc} (find $RPM_BUILD_ROOT%{_bindir} -type f | grep -vE "arch|svn|cvs|email|gitk" | sed -e s@^$RPM_BUILD_ROOT@@) > bin-man-doc-files
Signature · 1 line
1.4.0
Re: [PATCH 2, proof of concept] autoconf: Use %configure in git.spec, autoconf dependency only in rpm target
Hi Jakub,
Quoted 4 lines · Jakub Narebski
Sidenote 1: current git.spec.in doesn't allow building RPMS from a dirty version:
error: line 3: Illegal char '-' in version: Version: 1.4.1.g1c7c-dirty
Is it intentional?
I don't know if it's intentional, but it's annoying. The workaround is to use StGIT and run "stg refresh" before "make rpm".
Quoted 1 line
+Patch0: git-add-autoconf-configure.patch.gz
I don't think we need patches in git.spec.in. Let's leave it to the actual distributions. If you have a problem with rpm, please submit the autoconf support for now and the rest will be cleaned up eventually. Besides, the "next" branch has different and potentially conflicting changes to git.spec.in for Git.pm support.
Signature · 2 lines
Regards, Pavel Roskin
Re: [PATCH 2, proof of concept] autoconf: Use %configure in git.spec, autoconf dependency only in rpm target
Quoted 9 lines · Pavel Roskin
Quoted 1 line · Jakub Narebski
+Patch0: git-add-autoconf-configure.patch.gz
I don't think we need patches in git.spec.in. Let's leave it to the actual distributions. If you have a problem with rpm, please submit the autoconf support for now and the rest will be cleaned up eventually. Besides, the "next" branch has different and potentially conflicting changes to git.spec.in for Git.pm support.
First, it is proof of concept patch, the concept being having autoconf dependency _only_ in rpm target.
Second, it should be "Source1: autoconf-configure.tar.gz" or something like that. Using "Patch0:" was an ugly hack.
That to say RPM builders use "PatchN:" for patches which didn't made upstream; perhaps they make sources more compatibile with distribution RPM is prepared for.
Signature · 3 lines
Jakub Narebski Warsaw, Poland ShadeHawk on #git
Quoted 6 lines · Jakub Narebski
This is beginning of patch series introducing installation configuration using autoconf (and no other autotools) to git. The idea is to generate config.mak.autogen using ./configure (generated from configure.ac by running autoconf) from config.mak.in, so one can use autoconf as an _alternative_ to ordinary
Makefile, and creating one's own config.mak. Local settings in config.mak override generated settings in config.mak.autogen
Thanks. Applied with some trailing whitespace stripped, but not merged to "next" yet nor pushed out.
PATCH 1/1 Teach make clean about configure and autoconf
In reply to Jakub Narebski---
Part of this patch is needed also for handcrafted ./configure script (if not already przesent in some patch of those series)
Makefile | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
Makefile +2 -0
@@ -749,6 +749,8 @@ clean: $(LIB_FILE) $(XDIFF_LIB) rm -f $(ALL_PROGRAMS) $(BUILT_INS) git$X rm -f *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags + rm -rf autom4te.cache configure config.status config.cache + rm -f config.log config.mak.autogen rm -rf $(GIT_TARNAME) .doc-tmp-dir rm -f $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz rm -f $(htmldocs).tar.gz $(manpages).tar.gz
Signature · 1 line
1.4.0
[RFC/PATCH 3] Copy description of build configuration variables to configure.ac
Copy description of build configuration variables from the commentary in the top Makefile (from 'next' branch) to configure.ac, splitting them into "autoconf" sections.
This is to be able to easily check which build/install configuration variables are covered by current configure.ac
---
Please correct this if you feel that some variable was put in wrong section in configure.ac
configure.ac | 114 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 113 insertions(+), 1 deletions(-)
configure.ac +113 -1
@@ -9,6 +9,118 @@ AC_CONFIG_SRCDIR([git.c]) config_file=config.mak.autogen config_in=config.mak.in -# Output files + +## Checks for programs. +# Define NO_PYTHON if you want to loose all benefits of the recursive merge. + + +## Checks for libraries. +# Define NO_OPENSSL environment variable if you do not have OpenSSL. +# This also implies MOZILLA_SHA1. +# +# Define NO_CURL if you do not have curl installed. git-http-pull and +# git-http-push are not built, and you cannot use http:// and https:// +# transports. +# +# Define NO_EXPAT if you do not have expat installed. git-http-push is +# not built, and you cannot push using http:// and https:// transports. +# +# Define NEEDS_SSL_WITH_CRYPTO if you need -lcrypto with -lssl (Darwin). +# +# Define NEEDS_LIBICONV if linking with libc is not enough (Darwin). +# +# Define NEEDS_SOCKET if linking with libc is not enough (SunOS, +# Patrick Mauritz). + + +## Checks for header files. + + +## Checks for typedefs, structures, and compiler characteristics. +# Define NO_D_INO_IN_DIRENT if you don't have d_ino in your struct dirent. +# +# Define NO_D_TYPE_IN_DIRENT if your platform defines DT_UNKNOWN but lacks +# d_type in struct dirent (latest Cygwin -- will be fixed soonish). +# +# Define NO_SOCKADDR_STORAGE if your platform does not have struct +# sockaddr_storage. + + +## Checks for library functions. +# Define NO_STRCASESTR if you don't have strcasestr. +# +# Define NO_STRLCPY if you don't have strlcpy. +# +# Define NO_SETENV if you don't have setenv in the C library. +# +# Define NO_MMAP if you want to avoid mmap. +# +# Define NO_IPV6 if you lack IPv6 support and getaddrinfo(). +# +# Define NO_ICONV if your libc does not properly support iconv. + + +## Other checks. +# Define USE_PIC if you need the main git objects to be built with -fPIC +# in order to build and link perl/Git.so. x86-64 seems to need this. +# +# Define NO_SYMLINK_HEAD if you never want .git/HEAD to be a symbolic link. +# Enable it on Windows. By default, symrefs are still used. +# +# Define WITH_OWN_SUBPROCESS_PY if you want to use with python 2.3. +# +# Define NO_ACCURATE_DIFF if your diff program at least sometimes misses +# a missing newline at the end of the file. + + +## Site configuration +## --with-PACKAGE[=ARG] and --without-PACKAGE +# Define NO_SVN_TESTS if you want to skip time-consuming SVN interopability +# tests. These tests take up a significant amount of the total test time +# but are not needed unless you plan to talk to SVN repos. +# +# Define MOZILLA_SHA1 environment variable when running make to make use of +# a bundled SHA1 routine coming from Mozilla. It is GPL'd and should be fast +# on non-x86 architectures (e.g. PowerPC), while the OpenSSL version (default +# choice) has very fast version optimized for i586. +# +# Define PPC_SHA1 environment variable when running make to make use of +# a bundled SHA1 routine optimized for PowerPC. +# +# Define ARM_SHA1 environment variable when running make to make use of +# a bundled SHA1 routine optimized for ARM. +# +# Define NO_OPENSSL environment variable if you do not have OpenSSL. +# This also implies MOZILLA_SHA1. +# +# Define NO_CURL if you do not have curl installed. git-http-pull and +# git-http-push are not built, and you cannot use http:// and https:// +# transports. +# +# Define CURLDIR=/foo/bar if your curl header and library files are in +# /foo/bar/include and /foo/bar/lib directories. +# +# Define NO_EXPAT if you do not have expat installed. git-http-push is +# not built, and you cannot push using http:// and https:// transports. +# +# Define NO_MMAP if you want to avoid mmap. +# +# Define NO_PYTHON if you want to loose all benefits of the recursive merge. +# +## --enable-FEATURE[=ARG] and --disable-FEATURE +# Define COLLISION_CHECK below if you believe that SHA1's +# 1461501637330902918203684832716283019655932542976 hashes do not give you +# sufficient guarantee that no collisions between objects will ever happen. +# +# Define USE_NSEC below if you want git to care about sub-second file mtimes +# and ctimes. Note that you need recent glibc (at least 2.2.4) for this, and +# it will BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely +# randomly break unless your underlying filesystem supports those sub-second +# times (my ext3 doesn't). +# +# Define USE_STDEV below if you want git to care about the underlying device +# change being considered an inode change from the update-cache perspective. + +## Output files AC_CONFIG_FILES(["${config_file}":"${config_in}"]) AC_OUTPUT
Signature · 1 line
1.4.0
[RFC/PATCH 4] autoconf: Preparing the way for autodetection
Prepares configure.ac to output autodetected and selected (by using --with/--without and --enable/disable parameters to generated ./configure script) building configuration in "git style", i.e. by appending appropriate variables to output file config.mak.autogen (via temporary file config.mak.append).
---
This series of patches tries to build _optional_ automatic build and install configuration, using existing build configuration variables, and not making changes to Makefile.
Series of patches 4-8 adds automatic detection of compilation configuration (those which I could write easily).
configure.ac | 19 +++++++++++++++++-- 1 files changed, 17 insertions(+), 2 deletions(-)
configure.ac +17 -2
@@ -7,8 +7,19 @@ AC_INIT([git], [1.4.1], [[email protected] AC_CONFIG_SRCDIR([git.c]) config_file=config.mak.autogen +config_append=config.mak.append config_in=config.mak.in +echo "# ${config_append}. Generated by configure." > "${config_append}" + + +## Definitions of macros +# GIT_CONF_APPEND_LINE(LINE) +# -------------------------- +# Append LINE to file ${config_append} +AC_DEFUN([GIT_CONF_APPEND_LINE], +[echo "$1" >> "${config_append}"])# GIT_CONF_APPEND_LINE + ## Checks for programs. # Define NO_PYTHON if you want to loose all benefits of the recursive merge.
@@ -73,7 +84,7 @@ # Define NO_ACCURATE_DIFF if your diff p # a missing newline at the end of the file. -## Site configuration +## Site configuration ## --with-PACKAGE[=ARG] and --without-PACKAGE # Define NO_SVN_TESTS if you want to skip time-consuming SVN interopability # tests. These tests take up a significant amount of the total test time
@@ -121,6 +132,10 @@ # # Define USE_STDEV below if you want git to care about the underlying device # change being considered an inode change from the update-cache perspective. + ## Output files -AC_CONFIG_FILES(["${config_file}":"${config_in}"]) +AC_CONFIG_FILES(["${config_file}":"${config_in}":"${config_append}"]) AC_OUTPUT + +## Cleanup +rm -f "${config_append}"
Signature · 1 line
1.4.0
PATCH 1/1 autoconf: Checks for typedefs, structures, and compiler characteristics.
./configure script checks now for existence of the following types, structures, and structure members:
* dirent.d_ino in <dirent.h> (NO_D_INO_IN_DIRENT)
* dirent.d_type in <dirent.h> (NO_D_TYPE_IN_DIRENT)
* 'struct sockaddr_storage' in <netinet/in.h> (NO_SOCKADDR_STORAGE)
---
If on some systems other headers than written above are needed for specified types definitions, then it should be added to those tests.
configure.ac | 15 +++++++++++++-- 1 files changed, 13 insertions(+), 2 deletions(-)
configure.ac +13 -2
@@ -48,13 +48,24 @@ ## Checks for header files. ## Checks for typedefs, structures, and compiler characteristics. +AC_MSG_NOTICE([CHECKS for typedefs, structures, and compiler characteristics]) + # Define NO_D_INO_IN_DIRENT if you don't have d_ino in your struct dirent. -# +AC_CHECK_MEMBER(struct dirent.d_ino,[], +GIT_CONF_APPEND_LINE(NO_D_INO_IN_DIRENT=YesPlease), +[#include <dirent.h>]) + # Define NO_D_TYPE_IN_DIRENT if your platform defines DT_UNKNOWN but lacks # d_type in struct dirent (latest Cygwin -- will be fixed soonish). -# +AC_CHECK_MEMBER(struct dirent.d_type,[], +GIT_CONF_APPEND_LINE(NO_D_TYPE_IN_DIRENT=YesPlease), +[#include <dirent.h>]) + # Define NO_SOCKADDR_STORAGE if your platform does not have struct # sockaddr_storage. +AC_CHECK_TYPE(struct sockaddr_storage,[], +GIT_CONF_APPEND_LINE(NO_SOCKADDR_STORAGE=YesPlease), +[#include <netinet/in.h>]) ## Checks for library functions.
Signature · 1 line
1.4.0
[RFC/PATCH 6] autoconf: Checks for some library functions.
./configure script checks now for the following library functions:
* strcasestr (NO_STRCASESTR)
* strlcpy (NO_STRLCPY)
* setenv (NO_SETENV)
in default C library and in libraries which have AC_CHECK_LIB done for them.
Checks not implemented:
* NO_MMAP - probably only via optional features configuration
* NO_IPV6 - what does "lack IPv6 support" mean?
* NO_ICONV - what does "properly support iconv" mean?
---
Added only those checks I was sure how to do in autoconf.
Probably other, marked as not implemented checks either need custom test, or are more suited to site configuration section.
configure.ac | 15 ++++++++++++--- 1 files changed, 12 insertions(+), 3 deletions(-)
configure.ac +12 -3
@@ -69,12 +69,21 @@ GIT_CONF_APPEND_LINE(NO_SOCKADDR_STORAGE ## Checks for library functions. +## (in default C library and libraries checked by AC_CHECK_LIB) +AC_MSG_NOTICE([CHECKS for library functions]) + # Define NO_STRCASESTR if you don't have strcasestr. -# +AC_CHECK_FUNC(strcasestr,[], +GIT_CONF_APPEND_LINE(NO_STRCASESTR=YesPlease)) + # Define NO_STRLCPY if you don't have strlcpy. -# +AC_CHECK_FUNC(strlcpy,[], +GIT_CONF_APPEND_LINE(NO_STRLCPY=YesPlease)) + # Define NO_SETENV if you don't have setenv in the C library. -# +AC_CHECK_FUNC(setenv,[], +GIT_CONF_APPEND_LINE(NO_SETENV=YesPlease)) + # Define NO_MMAP if you want to avoid mmap. # # Define NO_IPV6 if you lack IPv6 support and getaddrinfo().
Signature · 1 line
1.4.0
[RFC/PATCH 7] autoconf: Checks for libraries
./configure script checks now if the following libraries are present:
* -lssl for SHA1_Init (NO_OPENSSL) * -lcurl for curl_easy_setopt (NO_CURL) * -lexpat for XML_ParserCreate (NO_EXPAT)
It also checks if adding the following libraries are needed:
* -lcrypto for SHA1_Init (NEEDS_SSL_WITH_CRYPTO)
* -liconv for iconv (NEEDS_LIBICONV)
* -lsocket for socket (NEEDS_SOCKET)
Policy: we check also if NEEDS_LIBRARY libraries are present, even if there is no NO_LIBRARY variable.
---
Needs checking if correct functions are used for checks.
Policy might need to be changed, too.
configure.ac | 28 +++++++++++++++++++++------- 1 files changed, 21 insertions(+), 7 deletions(-)
configure.ac +21 -7
@@ -26,22 +26,36 @@ # Define NO_PYTHON if you want to loose ## Checks for libraries. +AC_MSG_NOTICE([CHECKS for libraries]) + # Define NO_OPENSSL environment variable if you do not have OpenSSL. -# This also implies MOZILLA_SHA1. -# +# Define NEEDS_SSL_WITH_CRYPTO if you need -lcrypto with -lssl (Darwin). +AC_CHECK_LIB([ssl], [SHA1_Init],[], +[AC_CHECK_LIB([crypto], [SHA1_INIT], + GIT_CONF_APPEND_LINE(NEEDS_SSL_WITH_CRYPTO=YesPlease), + GIT_CONF_APPEND_LINE(NO_OPENSSL=YesPlease))]) + # Define NO_CURL if you do not have curl installed. git-http-pull and # git-http-push are not built, and you cannot use http:// and https:// # transports. -# +AC_CHECK_LIB([curl], [curl_global_init],[], +GIT_CONF_APPEND_LINE(NO_CURL=YesPlease)) + # Define NO_EXPAT if you do not have expat installed. git-http-push is # not built, and you cannot push using http:// and https:// transports. -# -# Define NEEDS_SSL_WITH_CRYPTO if you need -lcrypto with -lssl (Darwin). -# +AC_CHECK_LIB([expat], [XML_ParserCreate],[], +GIT_CONF_APPEND_LINE(NO_EXPAT=YesPlease)) + # Define NEEDS_LIBICONV if linking with libc is not enough (Darwin). -# +AC_CHECK_LIB([c], [iconv],[], +[AC_CHECK_LIB([iconv],[iconv], + GIT_CONF_APPEND_LINE(NEEDS_LIBICONV=YesPlease),[])]) + # Define NEEDS_SOCKET if linking with libc is not enough (SunOS, # Patrick Mauritz). +AC_CHECK_LIB([c], [socket],[], +[AC_CHECK_LIB([socket],[socket], + GIT_CONF_APPEND_LINE(NEEDS_SOCKET=YesPlease),[])]) ## Checks for header files.
Signature · 1 line
1.4.0
[RFC/PATCH 8] autoconf: Checks for some programs
./configure script checks now for the following programs:
* CC - using AC_PROG_CC
* AR - using AC_CHECK_TOOL among ar
* TAR - among gtar, tar
Checks not implemented:
* INSTALL - needs install-sh or install.sh in sources
* RPMBUILD - not known alternatives for rpmbuild
* PYTHON - no PYTHON variable in Makefile,
has to set NO_PYTHON if not present
---
If I remember correctly there was patch adding some very minimal install script for building git on some architecture. If it were added, the lines with INSTALL in configure.ac and config.mak.in should be uncommented in.
Currently it is commented out to ./configure not fail.
config.mak.in | 5 +++++ configure.ac | 7 +++++++ 2 files changed, 12 insertions(+), 0 deletions(-)
config.mak.in +5 -0
@@ -1,6 +1,11 @@ # git Makefile configuration, included in main Makefile # @configure_input@ +CC = @CC@ +AR = @AR@ +TAR = @TAR@ +#INSTALL = @INSTALL@ # needs install-sh or install.sh in sources + prefix = @prefix@ exec_prefix = @exec_prefix@ bindir = @bindir@
configure.ac +7 -0
@@ -22,6 +22,13 @@ AC_DEFUN([GIT_CONF_APPEND_LINE], ## Checks for programs. +AC_MSG_NOTICE([CHECKS for programs]) + +AC_PROG_CC +#AC_PROG_INSTALL # needs install-sh or install.sh in sources +AC_CHECK_TOOL(AR, ar, :) +AC_CHECK_PROGS(TAR, [gtar tar]) + # Define NO_PYTHON if you want to loose all benefits of the recursive merge.
Signature · 1 line
1.4.0
PATCH 1/1 configure.ac vertical whitespace usage cleanup
configure.ac | 29 +++++++++++++++-------------- 1 files changed, 15 insertions(+), 14 deletions(-)
configure.ac +15 -14
@@ -23,41 +23,41 @@ AC_DEFUN([GIT_CONF_APPEND_LINE], ## Checks for programs. AC_MSG_NOTICE([CHECKS for programs]) - +# AC_PROG_CC #AC_PROG_INSTALL # needs install-sh or install.sh in sources AC_CHECK_TOOL(AR, ar, :) AC_CHECK_PROGS(TAR, [gtar tar]) - +# # Define NO_PYTHON if you want to loose all benefits of the recursive merge. ## Checks for libraries. AC_MSG_NOTICE([CHECKS for libraries]) - +# # Define NO_OPENSSL environment variable if you do not have OpenSSL. # Define NEEDS_SSL_WITH_CRYPTO if you need -lcrypto with -lssl (Darwin). AC_CHECK_LIB([ssl], [SHA1_Init],[], [AC_CHECK_LIB([crypto], [SHA1_INIT], GIT_CONF_APPEND_LINE(NEEDS_SSL_WITH_CRYPTO=YesPlease), GIT_CONF_APPEND_LINE(NO_OPENSSL=YesPlease))]) - +# # Define NO_CURL if you do not have curl installed. git-http-pull and # git-http-push are not built, and you cannot use http:// and https:// # transports. AC_CHECK_LIB([curl], [curl_global_init],[], GIT_CONF_APPEND_LINE(NO_CURL=YesPlease)) - +# # Define NO_EXPAT if you do not have expat installed. git-http-push is # not built, and you cannot push using http:// and https:// transports. AC_CHECK_LIB([expat], [XML_ParserCreate],[], GIT_CONF_APPEND_LINE(NO_EXPAT=YesPlease)) - +# # Define NEEDS_LIBICONV if linking with libc is not enough (Darwin). AC_CHECK_LIB([c], [iconv],[], [AC_CHECK_LIB([iconv],[iconv], GIT_CONF_APPEND_LINE(NEEDS_LIBICONV=YesPlease),[])]) - +# # Define NEEDS_SOCKET if linking with libc is not enough (SunOS, # Patrick Mauritz). AC_CHECK_LIB([c], [socket],[],
@@ -70,18 +70,18 @@ ## Checks for header files. ## Checks for typedefs, structures, and compiler characteristics. AC_MSG_NOTICE([CHECKS for typedefs, structures, and compiler characteristics]) - +# # Define NO_D_INO_IN_DIRENT if you don't have d_ino in your struct dirent. AC_CHECK_MEMBER(struct dirent.d_ino,[], GIT_CONF_APPEND_LINE(NO_D_INO_IN_DIRENT=YesPlease), [#include <dirent.h>]) - +# # Define NO_D_TYPE_IN_DIRENT if your platform defines DT_UNKNOWN but lacks # d_type in struct dirent (latest Cygwin -- will be fixed soonish). AC_CHECK_MEMBER(struct dirent.d_type,[], GIT_CONF_APPEND_LINE(NO_D_TYPE_IN_DIRENT=YesPlease), [#include <dirent.h>]) - +# # Define NO_SOCKADDR_STORAGE if your platform does not have struct # sockaddr_storage. AC_CHECK_TYPE(struct sockaddr_storage,[],
@@ -92,19 +92,19 @@ GIT_CONF_APPEND_LINE(NO_SOCKADDR_STORAGE ## Checks for library functions. ## (in default C library and libraries checked by AC_CHECK_LIB) AC_MSG_NOTICE([CHECKS for library functions]) - +# # Define NO_STRCASESTR if you don't have strcasestr. AC_CHECK_FUNC(strcasestr,[], GIT_CONF_APPEND_LINE(NO_STRCASESTR=YesPlease)) - +# # Define NO_STRLCPY if you don't have strlcpy. AC_CHECK_FUNC(strlcpy,[], GIT_CONF_APPEND_LINE(NO_STRLCPY=YesPlease)) - +# # Define NO_SETENV if you don't have setenv in the C library. AC_CHECK_FUNC(setenv,[], GIT_CONF_APPEND_LINE(NO_SETENV=YesPlease)) - +# # Define NO_MMAP if you want to avoid mmap. # # Define NO_IPV6 if you lack IPv6 support and getaddrinfo().
@@ -178,5 +178,6 @@ ## Output files AC_CONFIG_FILES(["${config_file}":"${config_in}":"${config_append}"]) AC_OUTPUT + ## Cleanup rm -f "${config_append}"
Signature · 1 line
1.4.0
Comment on this series of patches (PATCH 2-9)
This concludes easiest part of autodetecting compile configuration using autoconf generated configure script. Patches needs revision by somebody better versed in autoconf than me.
Autodetection TODO:
* check for Python (NO_PYTHON) and it's version (WITH_OWN_SUBPROCESS_PY) or just "own subprocess.py"
* check for "IPv6 support" and getaddrinfo() (NO_IPV6), latter can be easily done in autoconf
* check for "proper iconv support" (NO_ICONV), probably custom check.
* check for USE_PIC, NO_SYMLINK_HEAD and NO_ACCURATE_DIFF, all needing custom tests.
* use XXX_SHA1 when NO_OPENSSL, with XXX according to the architecture git is compiled for.
Next planned are series of patches allowing to select optional build features and packages from configure script... if somebody else wouldn't do it (hint, hint).
About needing autoconf to build git:
1. Currently using autoconf is totally optional, so one can compile git as one used to earlier. This results in non-autoconf conventions in configure.ac
2. configure script generated by autoconf can be treated exactly the same like html and man documentation generated by asciidoc: use separate 'configure' branch to store current version of configure script, and add autogeneration of configure script to the same hook like generating html and man documentation.
Signature · 2 lines
Jakub Narebski ShadeHawk on #git
Re: Comment on this series of patches (PATCH 2-9)
Quoted 3 lines · Jakub Narebski
This concludes easiest part of autodetecting compile configuration using autoconf generated configure script. Patches needs revision by somebody better versed in autoconf than me.
Thanks. Will take a look.
Quoted 4 lines
About needing autoconf to build git:
1. Currently using autoconf is totally optional, so one can compile git as one used to earlier.
This should stay this way, at least for now and probably even after merging this into "master" someday (we need to get this in "next" first).
Quoted 5 lines
2. configure script generated by autoconf can be treated exactly the same like html and man documentation generated by asciidoc: use separate 'configure' branch to store current version of configure script, and add autogeneration of configure script to the same hook like generating html and man documentation.
Actually my gut feeling on this is eventually (read: when the autoconfiguration is stable enough) we would want to do this the other way around --- keep only the generated configure script for public consumption, and interested parties can check out autoconf branch to hack on configure.ac and friends when needed.
But we haven't reached that point yet, so we will see.
Re: [RFC/PATCH 3] Copy description of build configuration variables to configure.ac
In reply to Jakub NarebskiQuoted 3 lines · Jakub Narebski
Copy description of build configuration variables from the commentary in the top
Makefile(from 'next' branch) to configure.ac, splitting them into "autoconf" sections.
I do not see much point in this -- they will become out of sync.
Eventually when all the --with-* and --enable-* stuff are implemented, you can ask the generated configure what options are supported, so I do not think this would help the end user either. In other words it is strictly for supporting developers. I think you are better off making a list of supported and yet to be supported ones in the comment in configure.ac, and when you want to see if the list got stale over time, grep for '^# Define' from the Makefile and match them up.
Re: [RFC/PATCH 3] Copy description of build configuration variables to configure.ac
Quoted 6 lines · Junio C Hamano
Quoted 3 lines · Jakub Narebski
Copy description of build configuration variables from the commentary in the top
Makefile(from 'next' branch) to configure.ac, splitting them into "autoconf" sections.
Quoted 7 lines
I do not see much point in this -- they will become out of sync.
[...] I think you are better off making a list of supported and yet to be supported ones in the comment in configure.ac, and when you want to see if the list got stale over time, grep for '^# Define' from the
Makefileand match them up.
This is kind of such a list. Also let me point out that this was in _first_ patch of the series, as a kind of TODO list.
Perhaps those which are done, and those which are not implemented should be marked differently...
Signature · 3 lines
Jakub Narebski Warsaw, Poland ShadeHawk on #git
Re: [RFC/PATCH 3] Copy description of build configuration variables to configure.ac
Quoted 8 lines · Jakub Narebski
Quoted 5 lines
[...] I think you are better off making a list of supported and yet to be supported ones in the comment in configure.ac, and when you want to see if the list got stale over time, grep for '^# Define' from the
Makefileand match them up.This is kind of such a list. Also let me point out that this was in _first_ patch of the series, as a kind of TODO list.
Yes, you are right -- I spoke too early without realizing what was going on. The others build on this TODO list to fill the gap rather nicely.