README-hacking - autoconf - Git at Google


            
            -*- outline -*-


            These notes intend to help people working on the checked-out sources.

            
            These requirements do not apply when building from a distribution

            
            tarball.  Don't put this file into the distribution.  Don't mention it

            
            in the ChangeLog.  You may want to also see HACKING for

            
            maintainer-specific rules.


            * Requirements


            We've opted to keep only the highest-level sources in the GIT repository.

            
            This eases our maintenance burden, (fewer merges etc.), but imposes more

            
            requirements on anyone wishing to build from the just-checked-out sources.

            
            For example, you have to use recent stable versions of the maintainer

            
            tools we depend upon, including:


            - Automake 1.11+ <https://www.gnu.org/software/automake/>

            
            - Help2man 1.29+ <https://www.gnu.org/software/help2man/>

            
            - M4 1.4.16+ <https://www.gnu.org/software/m4/>

            
            - Perl 5.010+ <https://www.cpan.org/>

            
            - Texinfo 4.11+ <https://www.gnu.org/software/texinfo/>


            The following are useful as well, if you want to be able to run commands

            
            like "make dist-xz" or "make distcheck":


            - Gzip <https://www.gnu.org/software/gzip/>

            
            - Tar <https://www.gnu.org/software/tar/>

            
            - XZ Utils <https://tukaani.org/xz/>


            Although we try to keep the CVS mirror of the git repository usable,

            
            some of the tests in the testsuite will fail if git was not used to

            
            generate the version string.  Therefore, we recommend:


            - Git 1.4.4+ <https://git-scm.com/>


            You may find it useful to install the git-merge-changelog merge driver:

            
            https://git.savannah.gnu.org/cgit/gnulib.git/plain/lib/git-merge-changelog.c


            then add the following to .git/config or ~/.gitconfig:

            
            [merge "merge-changelog"]

            
            	name = GNU ChangeLog merge driver

            
            	driver = git-merge-changelog %O %A %B

            
            [diff "texinfo"]

            
            	funcname = ^@node[\t ][\t ]*\\([^,][^,]*\\)


            Only building the initial full source tree will be a bit painful.

            
            Later, a plain 'git pull && make' should be sufficient.


            If you want to test Autoconf on a machine without git, it may be

            
            easier to first bootstrap Autoconf on a different machine with git,

            
            run 'make dist', and copy the tarball to the machine under test.  It

            
            should always be possible to create a self-contained tarball which

            
            does not rely on the bootstrap-only tools.


            * First GIT checkout


            You can get an anonymous copy of the source repository using any one

            
            of these three methods, although the CVS mirror is less tested:


              $ git clone git://git.sv.gnu.org/autoconf

            
              $ git clone https://git.sv.gnu.org/r/autoconf.git

            
              $ cvs -d:pserver:anonymous@pserver.git.sv.gnu.org:/srv/git/autoconf.git \

            
                  co -d autoconf HEAD


            If you have a Savannah user name and commit rights to the Autoconf

            
            project, you should use this instead:


              $ git clone <username>@git.sv.gnu.org:/srv/git/autoconf.git


            The next step is to generate files like configure and Makefile.in:


              $ cd autoconf

            
              $ ./bootstrap


            The bootstrap script generates the same files ‘autoreconf -vi’ would,

            
            in a normal package, but it uses autoconf *from the git sources* to do

            
            it.  This means you do not need autoconf installed already, and you do

            
            not need to re-generate ‘configure’ after building Autoconf.


            You can now build and test the package:


              $ ./configure

            
              $ make

            
              $ make check


            At this point, there should be no difference between your local copy,

            
            and the GIT master copy:


              $ git diff


            should output no difference.


            The testsuite is run by 'make check'.  You may find it useful to run a

            
            subset of the testsuite; for example, all tests with the 'm4sugar'

            
            keyword as well as test 10:


              $ make check TESTSUITEFLAGS='10 -k m4sugar'


            You can pass options to configure scripts invoked by the testsuite by

            
            setting the configure_options variable:


              $ make check TESTSUITEFLAGS='configure_options="CC=gcc-2.95"'


            The test suite is not automatically parallelized by ‘make -j’.  If you

            
            want to parallelize the testsuite, you need to use TESTSUITEFLAGS for

            
            that, too:


              $ make check TESTSUITEFLAGS=-j8


            * Submitting patches


            All patches should be submitted to <autoconf-patches@gnu.org> for

            
            review, in context or unified diff format against the latest sources.

            
            In most cases, a patch should include a test case, to ensure that

            
            regressions do not creep back in.  Remember to add documentation and a

            
            NEWS entry for anything that is visible to the user.


            If your change is significant (i.e., if it adds more than ~10 lines),

            
            then you'll have to have a copyright assignment on file with the FSF.

            
            Since that involves first an email exchange between you and the FSF,

            
            and then the exchange (FSF to you, then back) of an actual sheet of paper

            
            with your signature on it, and finally, some administrative processing

            
            in Boston, the process can take a few weeks.


            The forms to choose from are in gnulib's doc/Copyright/ directory.

            
            If you want to assign a single change, you should use the file,

            
            doc/Copyright/request-assign.changes:


                https://git.sv.gnu.org/cgit/gnulib.git/tree/doc/Copyright/request-assign.changes


            If you would like to assign past and future autoconf work,

            
            you'd use doc/Copyright/request-assign.future:


                https://git.sv.gnu.org/cgit/gnulib.git/tree/doc/Copyright/request-assign.future


            Enjoy!


            -----


            Copyright (C) 2002-2017, 2020-2025 Free Software Foundation, Inc.


            Copying and distribution of this file, with or without modification,

            
            are permitted in any medium without royalty provided the copyright

            
            notice and this notice are preserved.  This file is offered as-is,

            
            without warranty of any kind.
	-- outline --

	These notes intend to help people working on the checked-out sources.
	These requirements do not apply when building from a distribution
	tarball. Don't put this file into the distribution. Don't mention it
	in the ChangeLog. You may want to also see HACKING for
	maintainer-specific rules.

	* Requirements

	We've opted to keep only the highest-level sources in the GIT repository.
	This eases our maintenance burden, (fewer merges etc.), but imposes more
	requirements on anyone wishing to build from the just-checked-out sources.
	For example, you have to use recent stable versions of the maintainer
	tools we depend upon, including:

	- Automake 1.11+ <https://www.gnu.org/software/automake/>
	- Help2man 1.29+ <https://www.gnu.org/software/help2man/>
	- M4 1.4.16+ <https://www.gnu.org/software/m4/>
	- Perl 5.010+ <https://www.cpan.org/>
	- Texinfo 4.11+ <https://www.gnu.org/software/texinfo/>

	The following are useful as well, if you want to be able to run commands
	like "make dist-xz" or "make distcheck":

	- Gzip <https://www.gnu.org/software/gzip/>
	- Tar <https://www.gnu.org/software/tar/>
	- XZ Utils <https://tukaani.org/xz/>

	Although we try to keep the CVS mirror of the git repository usable,
	some of the tests in the testsuite will fail if git was not used to
	generate the version string. Therefore, we recommend:

	- Git 1.4.4+ <https://git-scm.com/>

	You may find it useful to install the git-merge-changelog merge driver:
	https://git.savannah.gnu.org/cgit/gnulib.git/plain/lib/git-merge-changelog.c

	then add the following to .git/config or ~/.gitconfig:
	[merge "merge-changelog"]
	name = GNU ChangeLog merge driver
	driver = git-merge-changelog %O %A %B
	[diff "texinfo"]
	funcname = ^@node[\t ][\t ]\\([^,][^,]\\)

	Only building the initial full source tree will be a bit painful.
	Later, a plain 'git pull && make' should be sufficient.

	If you want to test Autoconf on a machine without git, it may be
	easier to first bootstrap Autoconf on a different machine with git,
	run 'make dist', and copy the tarball to the machine under test. It
	should always be possible to create a self-contained tarball which
	does not rely on the bootstrap-only tools.

	* First GIT checkout

	You can get an anonymous copy of the source repository using any one
	of these three methods, although the CVS mirror is less tested:

	$ git clone git://git.sv.gnu.org/autoconf
	$ git clone https://git.sv.gnu.org/r/autoconf.git
	$ cvs -d:pserver:anonymous@pserver.git.sv.gnu.org:/srv/git/autoconf.git \
	co -d autoconf HEAD

	If you have a Savannah user name and commit rights to the Autoconf
	project, you should use this instead:

	$ git clone <username>@git.sv.gnu.org:/srv/git/autoconf.git

	The next step is to generate files like configure and Makefile.in:

	$ cd autoconf
	$ ./bootstrap

	The bootstrap script generates the same files ‘autoreconf -vi’ would,
	in a normal package, but it uses autoconf from the git sources to do
	it. This means you do not need autoconf installed already, and you do
	not need to re-generate ‘configure’ after building Autoconf.

	You can now build and test the package:

	$ ./configure
	$ make
	$ make check

	At this point, there should be no difference between your local copy,
	and the GIT master copy:

	$ git diff

	should output no difference.

	The testsuite is run by 'make check'. You may find it useful to run a
	subset of the testsuite; for example, all tests with the 'm4sugar'
	keyword as well as test 10:

	$ make check TESTSUITEFLAGS='10 -k m4sugar'

	You can pass options to configure scripts invoked by the testsuite by
	setting the configure_options variable:

	$ make check TESTSUITEFLAGS='configure_options="CC=gcc-2.95"'

	The test suite is not automatically parallelized by ‘make -j’. If you
	want to parallelize the testsuite, you need to use TESTSUITEFLAGS for
	that, too:

	$ make check TESTSUITEFLAGS=-j8

	* Submitting patches

	All patches should be submitted to <autoconf-patches@gnu.org> for
	review, in context or unified diff format against the latest sources.
	In most cases, a patch should include a test case, to ensure that
	regressions do not creep back in. Remember to add documentation and a
	NEWS entry for anything that is visible to the user.

	If your change is significant (i.e., if it adds more than ~10 lines),
	then you'll have to have a copyright assignment on file with the FSF.
	Since that involves first an email exchange between you and the FSF,
	and then the exchange (FSF to you, then back) of an actual sheet of paper
	with your signature on it, and finally, some administrative processing
	in Boston, the process can take a few weeks.

	The forms to choose from are in gnulib's doc/Copyright/ directory.
	If you want to assign a single change, you should use the file,
	doc/Copyright/request-assign.changes:

	https://git.sv.gnu.org/cgit/gnulib.git/tree/doc/Copyright/request-assign.changes

	If you would like to assign past and future autoconf work,
	you'd use doc/Copyright/request-assign.future:

	https://git.sv.gnu.org/cgit/gnulib.git/tree/doc/Copyright/request-assign.future

	Enjoy!

	-----

	Copyright (C) 2002-2017, 2020-2025 Free Software Foundation, Inc.

	Copying and distribution of this file, with or without modification,
	are permitted in any medium without royalty provided the copyright
	notice and this notice are preserved. This file is offered as-is,
	without warranty of any kind.