mirror/patch
1
0
Fork 0
mirror of https://https.git.savannah.gnu.org/git/patch.git synced 2026-01-27 01:44:34 +00:00
Code Issues Packages Projects Releases Wiki Activity

maint: modernize README-{hacking,prereq}

Browse Source
This commit is contained in:
Paul Eggert 2021-10-30 16:28:25 -07:00
parent 7623b2dc0d
commit 24f81beb27
2 changed files with 87 additions and 38 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

89
README-hacking
View File

@ -1,40 +1,47 @@
-*- outline -*-
Building from a Git repository -*- outline -*-
These notes intend to help people working on the checked-out sources.
These requirements do not apply when building from a distribution tarball.
If this package has a file HACKING, please also read that file for
more detailed contribution guidelines.
* 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
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 the latest stable versions of the maintainer
tools we depend upon, including:
- Automake <http://www.gnu.org/software/automake/>
- Autoconf <http://www.gnu.org/software/autoconf/>
- Gettext <http://www.gnu.org/software/gettext/>
- Gzip <http://www.gnu.org/software/gzip/>
- M4 <http://www.gnu.org/software/m4/>
- Tar <http://www.gnu.org/software/tar/>
- Wget <http://www.gnu.org/software/wget/>
(The requirements to build from a release are much less and are just
the requirements of the standard './configure && make' procedure.)
Specific development tools and versions will be checked for and listed by
the bootstrap script. See README-prereq for specific notes on obtaining
these prerequisite tools.
Valgrind <http://valgrind.org/> is also highly recommended, if
Valgrind supports your architecture.
Valgrind supports your architecture. See also README-valgrind
(if present).
While building from a just-cloned source tree may require installing a
few prerequisites, later, a plain `git pull && make' should be sufficient.
few prerequisites, later, a plain 'git pull && make' typically suffices.
* First GIT checkout
* First Git checkout
You can get a copy of the source repository like this:
$ git clone git://git.sv.gnu.org/patch
$ cd patch
$ git clone git://git.sv.gnu.org/<packagename>
$ cd <packagename>
As an optional step, if you already have a copy of the gnulib git
repository on your hard drive, then you can use it as a reference to
reduce download time and disk space requirements:
where '<packagename>' stands for 'coreutils' or whatever other package
you are building.
To use the most-recent Gnulib (as opposed to the Gnulib version that
the package last synchronized to), do this next:
$ git submodule foreach git pull origin master
$ git commit -m 'build: update gnulib submodule to latest' gnulib
As an optional step, if you already have a copy of the Gnulib Git
repository, then you can use it as a reference to reduce download
time and file system space requirements:
$ export GNULIB_SRCDIR=/path/to/gnulib
@ -43,20 +50,14 @@ which are extracted from other source packages:
$ ./bootstrap
To use the most-recent gnulib (as opposed to the gnulib version that
the package last synchronized to), do this next:
$ git submodule foreach git pull origin master
$ git commit -m 'build: update gnulib submodule to latest' gnulib
And there you are! Just
$ ./configure --quiet
$ ./configure --quiet #[--disable-gcc-warnings] [*]
$ make
$ make check
At this point, there should be no difference between your local copy,
and the GIT master copy:
and the Git master copy:
$ git diff
@ -64,22 +65,34 @@ should output no difference.
Enjoy!
[*] By default GCC warnings are enabled when building from Git.
If you get warnings with recent GCC and Glibc with default
configure-time options, please report the warnings to the bug
reporting address of this package instead of to bug-gnulib,
even if the problem seems to originate in a Gnulib-provided file.
If you get warnings with other configurations, you can run
'./configure --disable-gcc-warnings' or 'make WERROR_CFLAGS='
to build quietly or verbosely, respectively.
-----
* Submitting patches
If you develop a fix or a new feature, please send it to the
appropriate bug-reporting address as reported by the --help option of
each program. One way to do this is to use vc-dwim
<http://www.gnu.org/software/vc-dwim/>), as follows.
<https://www.gnu.org/software/vc-dwim/>), as follows.
Run the command "vc-dwim --help", copy its definition of the
"git-changelog-symlink-init" function into your shell, and then run
this function at the top-level directory of the package.
Run the command "vc-dwim --initialize" from the top-level directory
of this package's git-cloned hierarchy.
Edit the ChangeLog file that this command creates, creating a
Edit the (empty) ChangeLog file that this command creates, creating a
properly-formatted entry according to the GNU coding standards
<http://www.gnu.org/prep/standards/html_node/Change-Logs.html>.
<https://www.gnu.org/prep/standards/html_node/Change-Logs.html>.
Run the command "vc-dwim" and make sure its output looks good.
Make your changes.
Run the command "vc-dwim" and make sure its output (the diff of all
your changes) looks good.
Run "vc-dwim --commit".
@ -88,7 +101,7 @@ each program. One way to do this is to use vc-dwim
-----
Copyright (C) 2002-2007, 2009-2012 Free Software Foundation, Inc.
Copyright (C) 2002-2021 Free Software Foundation, Inc.
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@ -101,4 +114,4 @@ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
along with this program. If not, see <https://www.gnu.org/licenses/>.

36
README-prereq Normal file
View File

@ -0,0 +1,36 @@
This gives some notes on obtaining the tools required for development.
These tools can be used by the 'bootstrap' and 'configure' scripts,
as well as by 'make'. They include:
- Autoconf <https://www.gnu.org/software/autoconf/>
- Automake <https://www.gnu.org/software/automake/>
- Git <https://git-scm.com/>
- Gzip <https://www.gnu.org/software/gzip/>
- M4 <https://www.gnu.org/software/m4/>
- Make <https://www.gnu.org/software/make/>
- Tar <https://www.gnu.org/software/tar/>
- Texinfo <https://www.gnu.org/software/texinfo/>
- Wget <http://www.gnu.org/software/wget/>
- XZ Utils <https://tukaani.org/xz/>
It is generally better to use official packages for your system.
If a package is not officially available you can build it from source
and install it into a directory that you can then use to build this
package. If some packages are available but are too old, install the
too-old versions first as they may be needed to build newer versions.
Here is an example of how to build a program from source. This
example is for Autoconf; a similar approach should work for the other
developer prerequisites. This example assumes Autoconf 2.71; it
should be OK to use a later version of Autoconf, if available.
prefix=$HOME/prefix # (or wherever else you choose)
export PATH=$prefix/bin:$PATH
wget https://ftp.gnu.org/pub/gnu/autoconf/autoconf-2.71.tar.gz
gzip -d <autoconf-2.71.tar.gz | tar xf -
cd autoconf-2.71
./configure --prefix=$prefix
make install
Once the prerequisites are installed, you can build this package as
described in README-hacking.