Re: GNU RCS 5.7.93 (pretest for 5.8) available

[Thien-Thi Nguyen]

() Ralf Wildenhues <address@hidden>
() Tue, 28 Sep 2010 20:10:38 +0200

   is that the right way to name you by the way?

That's fine.

   Bug report where to?  Don't forget to quote the bug address!

Good point; i have added bug-rcs to the CC.  Please include it in replies.

   I only looked at the git repo.  Questions that come to mind:

   - why are several files copyrighted by you, although this is a GNU
   package?  Do you not assign copyright to the FSF?  If you do, the file
   headers should say so, e.g.:

   # Copyright (C) 2010 Free Software Foundation, Inc.
   # Written by Thien-Thi Nguyen.
   #
   # This file is part of GNU RCS.

This is because RCS copyright was never assigned to FSF.  It has always
lain with the programmer (previously Paul Eggert and Walter F. Tichy).
That RCS is a GNU project is orthogonal.

   - How come you wrote your own test driver in v/Makefile.am?
   What's wrong with the one from automake?

Historical artifact, mostly; initially RCS did not use Automake (and
even for Autoconf, its use was very dated and incomplete -- a large
chunk of the configuration was actually done at "make all" time).  In my
efforts to reshape the build flow towards auto*, i initially emulated
the "user interface" (i.e., "make check" look and feel) of Automake
while keeping the underlying code.

With commit 9c48222fc0aa6a9bfb1d0208fe640924d5e6d35c (2010-03-19), i
began to actually use Automake but not to the full extent possible.  I
think it is now a good idea to make the complete transition.  Thanks for
the reminder.

That said, i have not yet played with autotest, and am ambivalent (lazy)
about trying.  For "make check" (and "make installcheck") RCS needs to
find its build-tree (and ‘bindir’, respectively) executables in
preference to any that have been installed on the system.  That's the
reason for the (decidedly inelegant) src/0pre/bin ‘PATH’ munging.  If
you could point me to autotest facilities that make fulfilling this
requirement easier, that would tip the balance for me.

   - A couple of your makefile recipes use
       cmd1; \
       cmd2; \
       ...

   which won't cause the recipe to fail reliably if cmd1 fails.
   Separate your commands with && if they need to be executed with one
   shell, and it is important to not neglect their status.  OTOH, some
   make implementation use 'sh -e' by default to execute recipes (which
   is actually required by the newest Posix), so they may fail
   unexpectedly.

Thanks for the tip.  I hope most of that hand-made code can go away with
better (more, idiomatic) Automake usage.