2007-10-27 18:14:35 +08:00
|
|
|
|
-*- outline -*-
|
|
|
|
|
|
|
|
|
|
|
|
These notes intend to help people working on the checked-out sources.
|
2008-04-10 00:15:28 +08:00
|
|
|
|
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.
|
2007-10-27 18:14:35 +08:00
|
|
|
|
|
|
|
|
|
|
* 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.
|
2008-04-15 20:56:56 +08:00
|
|
|
|
For example, you have to use recent stable versions of the maintainer
|
2007-10-27 18:14:35 +08:00
|
|
|
|
tools we depend upon, including:
|
|
|
|
|
|
|
2020-07-14 02:37:34 +08:00
|
|
|
|
- Automake 1.11+ <https://www.gnu.org/software/automake/>
|
2017-09-17 08:48:19 +08:00
|
|
|
|
- Help2man 1.29+ <https://www.gnu.org/software/help2man/>
|
2022-10-06 09:06:20 +08:00
|
|
|
|
- M4 1.4.16+ <https://www.gnu.org/software/m4/>
|
Go back to requiring only Perl 5.6+ for users
Commit 61901a1a14fd50c03cfb1529d091554376fef286 dated 2022-07-10
bumped the Perl requirement to 5.10 or later, because
commit 3a9802d60156809c139e9b4620bf04917e143ee2 dated 2021-08-31
added code using Time::HiRes’s ‘stat’ function, a feature
added in Perl 5.8.9+ or Perl 5.10+, and it was hard
to find Perl 5.8.9 hosts to test with. Also, requiring Perl 5.10
meant that we could then use operators like Digest::SHA, the // and
//= operators, the regexp \K escape, and ‘state’ variables.
However, that Time::HiRes code, which was taken from Automake, has
recently been made optional by Automake, and it now works again with
Perl 5.6. And Autoconf is not yet using any other post-5.6 feature,
except when developers run help-extract.pl (something Autoconf users
do not use). So relax the Autoconf user requirement back to 5.6 as it
was in Autoconf 2.71; although Autoconf developers will need 5.10 or
better, Autoconf users can get by with 5.6.
I ran into this problem when testing the Autoconf release candidate on
Solaris 10, which has Perl 5.8.4. Oracle says Solaris 10’s
end-of-life is January 2024, so it’s still (barely) a viable porting
target. Of course with Solaris 10 one must install a recent-enough
GNU m4, but adding a requirement to also install a recent-enough Perl
is a new barrier, and if it’s not needed then it might be better to
wait until it is needed (or until 2024 arrives).
* NEWS: Update news item about Perl 5.6 vs 5.10.
* README-hacking: Bump Perl recommendation to 5.10.
* build-aux/fetch.pl: Do not munge imported code to require 5.10.
2023-04-01 01:55:29 +08:00
|
|
|
|
- Perl 5.010+ <https://www.cpan.org/>
|
2020-07-14 02:37:34 +08:00
|
|
|
|
- Texinfo 4.11+ <https://www.gnu.org/software/texinfo/>
|
2007-10-28 22:25:01 +08:00
|
|
|
|
|
|
|
|
|
|
The following are useful as well, if you want to be able to run commands
|
2020-07-11 04:41:31 +08:00
|
|
|
|
like "make dist-xz" or "make distcheck":
|
2007-10-28 22:25:01 +08:00
|
|
|
|
|
2017-09-17 08:48:19 +08:00
|
|
|
|
- Gzip <https://www.gnu.org/software/gzip/>
|
|
|
|
|
|
- Tar <https://www.gnu.org/software/tar/>
|
2020-07-11 04:41:31 +08:00
|
|
|
|
- XZ Utils <https://tukaani.org/xz/>
|
2007-10-27 18:14:35 +08:00
|
|
|
|
|
2008-04-15 20:56:56 +08:00
|
|
|
|
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:
|
|
|
|
|
|
|
2017-09-24 03:45:22 +08:00
|
|
|
|
- Git 1.4.4+ <https://git-scm.com/>
|
2008-04-15 20:56:56 +08:00
|
|
|
|
|
|
|
|
|
|
You may find it useful to install the git-merge-changelog merge driver:
|
2020-12-01 00:41:23 +08:00
|
|
|
|
https://git.savannah.gnu.org/cgit/gnulib.git/plain/lib/git-merge-changelog.c
|
2008-04-15 20:56:56 +08:00
|
|
|
|
|
2008-08-18 20:25:49 +08:00
|
|
|
|
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 ]*\\([^,][^,]*\\)
|
|
|
|
|
|
|
2007-10-27 18:14:35 +08:00
|
|
|
|
Only building the initial full source tree will be a bit painful.
|
2021-07-21 05:01:43 +08:00
|
|
|
|
Later, a plain 'git pull && make' should be sufficient.
|
2007-10-27 18:14:35 +08:00
|
|
|
|
|
2008-04-15 20:56:56 +08:00
|
|
|
|
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,
|
2021-07-21 05:01:43 +08:00
|
|
|
|
run 'make dist', and copy the tarball to the machine under test. It
|
2008-04-15 20:56:56 +08:00
|
|
|
|
should always be possible to create a self-contained tarball which
|
|
|
|
|
|
does not rely on the bootstrap-only tools.
|
|
|
|
|
|
|
2007-10-27 18:14:35 +08:00
|
|
|
|
* First GIT checkout
|
|
|
|
|
|
|
2008-04-10 00:15:28 +08:00
|
|
|
|
You can get an anonymous copy of the source repository using any one
|
|
|
|
|
|
of these three methods, although the CVS mirror is less tested:
|
2007-10-27 18:14:35 +08:00
|
|
|
|
|
2008-04-10 00:15:28 +08:00
|
|
|
|
$ git clone git://git.sv.gnu.org/autoconf
|
2017-09-17 08:48:19 +08:00
|
|
|
|
$ git clone https://git.sv.gnu.org/r/autoconf.git
|
2008-04-10 00:15:28 +08:00
|
|
|
|
$ 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
|
2007-10-27 18:14:35 +08:00
|
|
|
|
|
|
|
|
|
|
The next step is to generate files like configure and Makefile.in:
|
|
|
|
|
|
|
2008-04-10 00:15:28 +08:00
|
|
|
|
$ cd autoconf
|
Add a bootstrap script like Automake has.
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 people building from git do not need autoconf to be
installed already. More importantly, it eliminates the extra steps
when building from git, of re-generating autoconf’s own configure
script with the just-built autoconf, then rebuilding the entire tree.
(This process still requires Automake to be installed already, and
Automake’s bootstrap script requires Autoconf to be installed already,
so there is still a dependency loop between Autoconf and Automake when
building from git—you need at least one of them installed from a
tarball to get started.)
The bootstrap script works by creating a partial installation tree in
a temporary directory, containing bin/autoconf, bin/autom4te, and just
enough of the usual contents of $(pkgdatadir) for autoconf and
autom4te to work. It then runs a hardcoded list of commands,
corresponding to what ‘autoreconf -i -Wall,error’ would run, but
setting environment variables AUTOCONF and AUTOM4TE to ensure the
bootstrap versions of these tools are used. (We have to create both,
because automake runs autoconf, not autom4te, to trace configure.ac.)
The ‘Autom4te’, ‘autoconf’, and ‘m4sugar’ subdirectories of the
partial installation tree are symlinked back to the source tree; this
is why version.m4 needed to be moved out of the m4sugar subdirectory,
so the bootstrap script can create it without scribbling on the source
tree. autom4te is run in --melt mode, so we don’t need to create
freeze files in any subdirectories either. All of the substitution
variables that are needed for autoconf and autom4te to both run, and
create the same output that they would have if fully configured, are
honored (unfortunately this does involve digging around in
configure.ac with sed expressions).
2021-02-05 02:11:28 +08:00
|
|
|
|
$ ./bootstrap
|
2007-10-27 18:14:35 +08:00
|
|
|
|
|
Add a bootstrap script like Automake has.
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 people building from git do not need autoconf to be
installed already. More importantly, it eliminates the extra steps
when building from git, of re-generating autoconf’s own configure
script with the just-built autoconf, then rebuilding the entire tree.
(This process still requires Automake to be installed already, and
Automake’s bootstrap script requires Autoconf to be installed already,
so there is still a dependency loop between Autoconf and Automake when
building from git—you need at least one of them installed from a
tarball to get started.)
The bootstrap script works by creating a partial installation tree in
a temporary directory, containing bin/autoconf, bin/autom4te, and just
enough of the usual contents of $(pkgdatadir) for autoconf and
autom4te to work. It then runs a hardcoded list of commands,
corresponding to what ‘autoreconf -i -Wall,error’ would run, but
setting environment variables AUTOCONF and AUTOM4TE to ensure the
bootstrap versions of these tools are used. (We have to create both,
because automake runs autoconf, not autom4te, to trace configure.ac.)
The ‘Autom4te’, ‘autoconf’, and ‘m4sugar’ subdirectories of the
partial installation tree are symlinked back to the source tree; this
is why version.m4 needed to be moved out of the m4sugar subdirectory,
so the bootstrap script can create it without scribbling on the source
tree. autom4te is run in --melt mode, so we don’t need to create
freeze files in any subdirectories either. All of the substitution
variables that are needed for autoconf and autom4te to both run, and
create the same output that they would have if fully configured, are
honored (unfortunately this does involve digging around in
configure.ac with sed expressions).
2021-02-05 02:11:28 +08:00
|
|
|
|
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:
|
2007-10-27 18:14:35 +08:00
|
|
|
|
|
2008-04-10 00:15:28 +08:00
|
|
|
|
$ ./configure
|
|
|
|
|
|
$ make
|
|
|
|
|
|
$ make check
|
2007-10-27 18:14:35 +08:00
|
|
|
|
|
|
|
|
|
|
At this point, there should be no difference between your local copy,
|
|
|
|
|
|
and the GIT master copy:
|
|
|
|
|
|
|
2008-04-10 00:15:28 +08:00
|
|
|
|
$ git diff
|
2007-10-27 18:14:35 +08:00
|
|
|
|
|
|
|
|
|
|
should output no difference.
|
|
|
|
|
|
|
2008-04-10 00:15:28 +08:00
|
|
|
|
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'
|
|
|
|
|
|
|
2009-09-14 00:03:31 +08:00
|
|
|
|
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"'
|
|
|
|
|
|
|
Add a bootstrap script like Automake has.
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 people building from git do not need autoconf to be
installed already. More importantly, it eliminates the extra steps
when building from git, of re-generating autoconf’s own configure
script with the just-built autoconf, then rebuilding the entire tree.
(This process still requires Automake to be installed already, and
Automake’s bootstrap script requires Autoconf to be installed already,
so there is still a dependency loop between Autoconf and Automake when
building from git—you need at least one of them installed from a
tarball to get started.)
The bootstrap script works by creating a partial installation tree in
a temporary directory, containing bin/autoconf, bin/autom4te, and just
enough of the usual contents of $(pkgdatadir) for autoconf and
autom4te to work. It then runs a hardcoded list of commands,
corresponding to what ‘autoreconf -i -Wall,error’ would run, but
setting environment variables AUTOCONF and AUTOM4TE to ensure the
bootstrap versions of these tools are used. (We have to create both,
because automake runs autoconf, not autom4te, to trace configure.ac.)
The ‘Autom4te’, ‘autoconf’, and ‘m4sugar’ subdirectories of the
partial installation tree are symlinked back to the source tree; this
is why version.m4 needed to be moved out of the m4sugar subdirectory,
so the bootstrap script can create it without scribbling on the source
tree. autom4te is run in --melt mode, so we don’t need to create
freeze files in any subdirectories either. All of the substitution
variables that are needed for autoconf and autom4te to both run, and
create the same output that they would have if fully configured, are
honored (unfortunately this does involve digging around in
configure.ac with sed expressions).
2021-02-05 02:11:28 +08:00
|
|
|
|
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
|
|
|
|
|
|
|
2008-04-10 00:15:28 +08:00
|
|
|
|
* 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:
|
|
|
|
|
|
|
2020-12-01 00:41:23 +08:00
|
|
|
|
https://git.sv.gnu.org/cgit/gnulib.git/tree/doc/Copyright/request-assign.changes
|
2008-04-10 00:15:28 +08:00
|
|
|
|
|
|
|
|
|
|
If you would like to assign past and future autoconf work,
|
|
|
|
|
|
you'd use doc/Copyright/request-assign.future:
|
|
|
|
|
|
|
2020-12-01 00:41:23 +08:00
|
|
|
|
https://git.sv.gnu.org/cgit/gnulib.git/tree/doc/Copyright/request-assign.future
|
2008-04-10 00:15:28 +08:00
|
|
|
|
|
2007-10-27 18:14:35 +08:00
|
|
|
|
Enjoy!
|
|
|
|
|
|
|
|
|
|
|
|
-----
|
|
|
|
|
|
|
2024-01-06 01:11:48 +08:00
|
|
|
|
Copyright (C) 2002-2017, 2020-2024 Free Software Foundation, Inc.
|
2007-10-27 18:14:35 +08:00
|
|
|
|
|
2009-05-04 23:41:41 +08:00
|
|
|
|
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.
|
