[PATCH 6/6] maint: use sed instead of maintaining 2 README files.

[Gary V. Vaughan]

* README.alpha: Deleted.  It was mostly identical to README.
* libltdl/config/edit-readme-alpha: New script to edit the
contents of README in the dist tree prior to tarring up.
* Makefile.am (dist-hook): Run it before rolling alpha release
tarball.
---
 ChangeLog                        |    7 +
 Makefile.am                      |   11 +-
 README.alpha                     |  324 --------------------------------------
 libltdl/config/edit-readme-alpha |   49 ++++++
 4 files changed, 63 insertions(+), 328 deletions(-)
 delete mode 100644 README.alpha
 create mode 100755 libltdl/config/edit-readme-alpha

diff --git a/ChangeLog b/ChangeLog
index a4781d9..05c4466 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,12 @@
 2010-09-18  Gary V. Vaughan  <address@hidden>
 
+       maint: use sed instead of maintaining 2 README files.
+       * README.alpha: Deleted.  It was mostly identical to README.
+       * libltdl/config/edit-readme-alpha: New script to edit the
+       contents of README in the dist tree prior to tarring up.
+       * Makefile.am (dist-hook): Run it before rolling alpha release
+       tarball.
+
        maint: improve README's `Obtaining the Latest Sources'.
        * README (Obtaining the Latest Sources): Add instructions for
        obtaining stable, alpha and nightly snapshot tarballs.
diff --git a/Makefile.am b/Makefile.am
index dcd0876..6e29a29 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -406,6 +406,10 @@ install-data-local: libltdl/Makefile.in
 ## Distribution. ##
 ## ------------- ##
 
+edit_readme_alpha = $(auxdir)/edit-readme-alpha
+
+EXTRA_DIST += $(edit_readme_alpha)
+
 uninstall-hook:
        @$(NORMAL_UNINSTALL)
        @list='$(ltdldatafiles) $(auxfiles)'; for f in $$list; do \
@@ -419,11 +423,10 @@ uninstall-hook:
        done
 
 dist-hook:
-## Ship README.alpha only in alpha release, but renamed to README
-       @if test -f $(srcdir)/README.alpha; then \
+## Edit the README file for alpha releases.
        case $(VERSION) in \
-         *[a-z]) cp -p $(srcdir)/README.alpha $(distdir)/README ;; \
-       esac; else :; fi
+         *[a-z]) $(SHELL) $(srcdir)/$(edit_readme_alpha) $(distdir)/README ;; \
+       esac
 ## Ensure aclocal has not wrongly picked up old macro definitions.
        for macro in LT_INIT AC_PROG_LIBTOOL AM_PROG_LIBTOOL; do \
          if grep $$macro $(srcdir)/aclocal.m4 $(srcdir)/libltdl/aclocal.m4; 
then \
diff --git a/README.alpha b/README.alpha
deleted file mode 100644
index 1771124..0000000
--- a/README.alpha
+++ /dev/null
@@ -1,324 +0,0 @@
-GNU Libtool
-***********
-
-1. Introduction
-===============
-
-This is an alpha testing release of GNU Libtool, a generic library
-support script.  Libtool hides the complexity of using shared libraries
-behind a consistent, portable interface.
-
-Libtool's home page is:
-
-    http://www.gnu.org/software/libtool/libtool.html
-
-See the file NEWS for a description of recent changes to Libtool.
-
-See the file INSTALL for generic instructions on how to build and
-install Libtool.  Please see the file doc/notes.txt for some platform-
-specific information.  Please note that you need GNU make to build
-Libtool.
-
-See the info node (libtool)Tested Platforms. (or the file doc/PLATFORMS)
-for a list of platforms that Libtool already supports.
-
-Please try it on all the platforms you have access to:
-
- * If it builds and passes the test suite (`gmake check'), please send
-   a short note to the libtool mailing list <address@hidden> with a
-   subject line including the string `[PLATFORM]', and containing the
-   details from the end of `./libtool --help' in the body.
- * Otherwise, see `Reporting Bugs' below for how to help us fix any
-   problems you discover.
-
-To use Libtool, add the new generic library building commands to your
-Makefile, Makefile.in, or Makefile.am.  See the documentation for
-details.
-
-
-2. Reporting Bugs
-=================
-
-If this distribution doesn't work for you, before you report the
-problem, at least try upgrading to the latest released version first,
-and see whether the issue persists.  If you feel able, you can also
-check whether the issue has been fixed in the development sources for
-the next release (see `Obtaining the Latest Sources' below).
-
-Once you've determined that your bug is still not fixed in the latest
-version, please send a full report to <address@hidden>, including:
-
-  1. the information from the end of the help message given by
-     `./libtool --help', and the verbose output of any failed tests
-     (see `The Test Suites' immediately below);
-  2. complete instructions for how to reproduce your bug, along with
-     the results you were expecting, and how they differ from what you
-     actually see;
-  3. a workaround or full fix for the bug, if you have it;
-  4. a copy of `tests/testuite.log' if you are experiencing failures
-     in the Autotest testsuite.
-  5. new test cases for the testsuite that demonstrate the bug are
-     especially welcome, and will help to ensure that future releases
-     don't reintroduce the problem - if you're not able to write a
-     complete testsuite case, a simple standalone shell script is
-     usually good enough to help us write a test for you.
-
-If you have any other suggestions, or if you wish to port Libtool to a
-new platform, please send email to the mailing list <address@hidden>.
-
-Please note that if you send us an non-trivial code for inclusion in a
-future release, we may ask you for a copyright assignment (for brief
-details see the `Copyright Assignment' section on our `Contributing'
-webpage <http://www.gnu.org/software/libtool/contribute.html>).
-
-
-3. The Test Suites
-==================
-
-Libtool comes with two integrated sets of tests to check that your build
-is sane.  You can run both test suites like this, assuming that `gmake'
-refers to GNU make:
-
-    gmake -k check
-
-If you want to run the old testsuite only, do it like this:
-
-    gmake check TESTSUITEFLAGS=-V
-
-If you want to run the new testsuite only, do it like this:
-
-    gmake check-local
-
-The tests of the old test suite run in groups in the various demo
-subdirectories, so if one of the tests early in a group FAILs, the rest
-of the tests in that group will be SKIPped.  If you see a FAIL further
-into a group, even if a test with the same name PASSes in another test
-group, you need to take note of the name of the first test in the group
-if you want to rerun the group with FAILures to get verbose output.
-
-To run a test group of the old test suite in isolation (say, you think
-you have fixed a bug, but don't want to rerun the entire suite), you can
-do it like this:
-
-    gmake check TESTSUITEFLAGS=-V TESTS="tests/cdemo-static.test \
-        tests/cdemo-static-make.test tests/cdemo-static-exec.test"
-
-Providing that you have a FAIL from the most recent group from a
-particular demo directory (like the cdemo-static.test group above), you
-can explore the state of the directory to help with debugging.
-
-If you wish to report a test group failure to the libtool list, you need
-to send the verbose output of the FAILing group, along with the
-information from the end of `$(top_builddir)/libtool --help' to the bug
-report mailing list, <address@hidden> with a subject line that
-includes the string `[TEST FAILURE]'.  The file test-suite.log contains
-the verbose output from all failed tests.
-
-In order to enable debug shell tracing, you can set VERBOSE=debug when
-running the old test suite.
-
-In the long run, Libtool will move to using only the new, Autotest-
-driven testsuite.  Its usage is documented in:
-
-    info Autoconf 'testsuite Invocation'
-
-but simple help may also be obtained through:
-
-    gmake check-local TESTSUITEFLAGS='--help'
-
-For verbose output, add the flag `-v', for running only a subset of the
-independent tests, merely specify them by number or by keyword, both of
-which are displayed with the `--list' flag.  For example, the `libtool'
-keyword is used for the tests that exercise only this script.  So it is
-possible to test an installed script, possibly from a different Libtool
-release, with:
-
-    gmake check-local \
-        TESTSUITEFLAGS="-k libtool LIBTOOL=/path/to/libtool"
-
-Some tests, like the one exercising max_cmd_len limits, make use of this
-to invoke the testsuite recursively on a subset of tests.  For these
-tests, the variable INNER_TESTSUITEFLAGS may be used.  It will be
-expanded right after the `-k libtool', without separating whitespace, so
-that further limiting of the recursive set of tests is possible.  For
-example, to run only the template tests within the max_cmd_len, use:
-
-    gmake check-local TESTSUITEFLAGS="-v -x -k max_cmd_len \
-                     INNER_TESTSUITEFLAGS=',template -v -x'"
-
-If you wish to report test failures to the libtool list, you need to
-send the file `tests/testsuite.log' to the bug report mailing list,
-<address@hidden>.
-
-
-4. Obtaining the Latest Sources
-===============================
-
-* With the exception of ancient releases, all official GNU Libtool
-  releases have a detached GPG signature file.  With this you can verify
-  that the corresponding file (i.e. without the `.sig' suffix) is the
-  same file that was released by the owner of it's GPG key ID.  First,
-  be sure to download both the .sig file and the corresponding release,
-  then run a command like this:
-
-    gpg --verify libtool-x.y.z.tar.gz.sig
-
-  If that command fails because you don't have the required public key,
-  then run this command to import it:
-
-    gpg --keyserver keys.gnupg.net --recv-keys 2983D606
-
-  and then rerun the `gpg --verify' command.
-
-* Official stable releases of GNU Libtool, along with these detached
-  signature files are available from:
-
-    ftp://ftp.gnu.org/gnu/libtool
-
-  To reduce load on the main server, please use one of the mirrors
-  listed at:
-
-    http://www.gnu.org/order/ftp.html
-
-* Alpha quality pre-releases of GNU Libtool, also with detached
-  signature files are available from:
-
-    ftp://alpha.gnu.org/gnu/libtool
-
-  and some of the mirrors listed at:
-
-    http://www.gnu.org/order/ftp.html
-
-* Nightly snapshots of the unreleased development trunk of GNU Libtool
-  are available from:
-
-    http://pogma.com/libtool
-
-  These files do not have signatures, but will allow you to easily
-  determine whether the most recent development code still exhibits any
-  bugs you have discovered, without requiring you to install a complete
-  build environment and the extra tools needed to bootstrap a version
-  control checkout.
-
-* The master libtool repository is stored in git.
-
-  If you are a member of the savannah group for GNU Libtool, a writable
-  copy of the libtool repository can be obtained by:
-
-    git clone <savannah-user>@git.sv.gnu.org:/srv/git/libtool.git
-
-  If you are behind a firewall that blocks the git protocol, you may
-  find it useful to use
-
-    git config --global url.http://git.sv.gnu.org/r/.insteadof \
-      git://git.sv.gnu.org/
-
-  to force git to transparently rewrite all savannah git references to
-  use http.
-
-  If you are not a member of the savannah group for GNU Libtool, you can
-  still fetch a read-only copy with either:
-
-    git clone git://git.sv.gnu.org/libtool.git
-
-  or using the CVS pserver protocol:
-
-    cvs -d:pserver:address@hidden:/srv/git/libtool.git \
-        co -d libtool HEAD
-
-* Before you can build from git, you need to bootstrap.  This requires:
-  - Autoconf 2.62 or later
-  - Automake 1.11.1 or later
-  - Help2man 1.29 or later
-  - Xz 4.999.8beta or later (from <http://tukaani.org/xz>)
-  - Texinfo 4.8 or later
-  - Any prerequisites of the above (such as m4, perl, tex)
-
-  Note that these bootstrapping dependencies are much stricter than
-  those required to use a destributed release for your own packages.
-  After installation, GNU Libtool is designed to work either standalone,
-  or optionally with:
-  - Autoconf 2.59 or later
-  - Automake 1.9.6 or later
-
-* The `bootstrap' script sets up the source directory for you to hack,
-  though it may take quite some time to run.  If you don't intend to
-  re-run the test suite, you can speed up the `bootstrap' step by an
-  order of magnitude if you call it like this instead:
-
-    reconfdirs='. libltdl' ./bootstrap
-
-
-5. Version Numbering
-====================
-
-People have complained that they find the version numbering scheme under
-which libtool is released confusing... so we've changed it!
-
-It works like this:
-
-       <major-number>.<minor-number>
-
-Releases with a <major-number> less than 1 were not yet feature
-complete.  Releases with a <major-number> of 1 used the old numbering
-scheme that everyone disliked so much.  Releases with a <major-number>
-of 2 us the new scheme described here.  If libtool ever undergoes a
-major rewrite or substantial restructuring, the <major-number> will be
-incremented again.
-
-If we make a patch release to fix bugs in a stable release, we use a
-third number, so:
-
-      <major-number>.<minor-number>.<micro-number>
-
-Version numbers are chosen to make it easy for users to decide two
-things:
-
-  Q: How `developed' is this release?
-  A: The higher the number, the better!
-  Q: How `stable' is this release?
-  A: - If the <minor-number> is even, it is a stable release, `2.0'.
-     - If the <minor-number> is odd, it is a development version with
-       new features compared to the last stable release, `2.1a'.
-     - If it has an `odd'[1] letter after the version number,  it is a
-       snapshot direct from CVS, `2.1a'.
-     - If it has an `even'[1] letter after the version number, it is an
-       alpha quality release, `2.1b'.
-     - If it has three numbers in the version, it is a patch release,
-       fixing bugs from the stable release (with no new features), `2.0.1'.
-
-[1] We always increment the letter in the repository before *and* after
-    making a release tarball.  This means that "odd" letters
-    (a,c,e,g...) only exist in the repository, and "even" letters are
-    used instantaneously for an alpha release.  Since the odd lettered
-    version numbers cover many states of the tree, we also qualify them
-    by adding the cvs version of the ChangeLog:
-
-    $ libtool --version
-    ltmain.sh (GNU libtool 1.1603 2004/09/12 22:02:07) 2.1a
-
-    Copyright (C) 2004  Free Software Foundation, Inc.
-    This is free software; see the source for copying conditions.  There is NO
-    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-
-For more details about version numbers, see:
-
-    http://www.gnu.org/software/libtool/contribute.html
---
-  Copyright (C) 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software
-  Foundation, Inc.
-  Written by Gary V. Vaughan, 2004
-
-  This file is part of GNU Libtool.
-
-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.
-
-
-Local Variables:
-mode: text
-fill-column: 72
-End:
-vim:tw=72
diff --git a/libltdl/config/edit-readme-alpha b/libltdl/config/edit-readme-alpha
new file mode 100755
index 0000000..780c35f
--- /dev/null
+++ b/libltdl/config/edit-readme-alpha
@@ -0,0 +1,49 @@
+#! /bin/sh
+
+#   edit-readme-alpha - edit README file for alpha releases
+#   Copyright (C) 2010 Free Software Foundation, Inc.
+#   Written by Gary V. Vaughan, 2010
+#
+#   This file is part of GNU Libtool.
+#
+# GNU Libtool is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# GNU Libtool is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# 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 GNU Libtool; see the file COPYING.  If not, a copy
+# can be downloaded from  http://www.gnu.org/licenses/gpl.html,
+# or obtained by writing to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+####
+
+# We used to maintain separate (but extremely similiar!) README and
+# README.alpha files, and had `make dist' include the right one in a
+# distribution based on the contests of `$(VERSION)'.
+#
+# Now, we have `make dist' call this script to tweak the first paragraph
+# of README in situ, to be more suitable for an alpha quality release.
+
+for file in "$@"; do
+  trap 'x=$?; rm $file.T; exit $x' 1 2 13 15
+
+  sed -e '/^This is GNU Libtool,/,/^interface.$/c\
+This is an alpha testing release of GNU Libtool, a generic library\
+support script.  Libtool hides the complexity of using shared libraries\
+behind a consistent, portable interface.' $file > $file.T \
+    && mv -f $file.T $file
+
+  test -f $file.T && {
+    rm $file.T
+    echo "$0: unable to edit $file"
+    exit 1
+  }
+done
+
+exit 0
-- 
1.7.2.2