maint: modernize README-{hacking,prereq}

2 files changed, 87 insertions, 38 deletions

diff --git a/README-hacking b/README-hacking
index 9a0e1b2..44cb75b 100644
--- a/README-hacking
+++ b/README-hacking
@@ -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>
+
+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 on your hard drive, then you can use it as a reference to
-reduce download time and disk space requirements:
+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>.
+
+  Make your changes.
 
-  Run the command "vc-dwim" and make sure its output looks good.
+  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/>.
diff --git a/README-prereq b/README-prereq
new file mode 100644
index 0000000..913441b
--- /dev/null
+++ b/README-prereq
@@ -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.