maint: modernize README-{hacking,prereq}

2 files changed, 81 insertions, 35 deletions

diff --git a/README-hacking b/README-hacking
index 5ee8cbe..44cb75b 100644
--- a/README-hacking
+++ b/README-hacking
@@ -1,36 +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.
-See also HACKING for more detailed contribution guidelines.
+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.
-Note the requirements to build the released archive are much less and
-are just the requirements of the standard ./configure && make procedure.
+(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/diffutils
-        $ cd diffutils
+        $ 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
 
@@ -39,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 #[--enable-gcc-warnings] [*]
+        $ ./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
 
@@ -60,27 +65,29 @@ should output no difference.
 
 Enjoy!
 
-[*] The --enable-gcc-warnings option is useful only with glibc
-and with a very recent version of gcc.  You'll probably also have
-to use recent system headers.  If you configure with this option,
-and spot a problem, please be sure to send the report to the bug
-reporting address of this package, and not to that of gnulib, even
-if the problem seems to originate in a gnulib-provided file.
+[*] 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 (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.
 
@@ -94,7 +101,7 @@ each program.  One way to do this is to use vc-dwim
 
 -----
 
-Copyright (C) 2002-2007, 2009-2013, 2015-2021 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
@@ -107,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..72eece7
--- /dev/null
+++ b/README-prereq
@@ -0,0 +1,39 @@
+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/>
+- Gettext    <https://www.gnu.org/software/gettext/>
+- Git        <https://git-scm.com/>
+- Gzip       <https://www.gnu.org/software/gzip/>
+- Help2man   <https://www.gnu.org/software/help2man/>
+- M4         <https://www.gnu.org/software/m4/>
+- Make       <https://www.gnu.org/software/make/>
+- Perl       <https://www.cpan.org/>
+- 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.