Re: [bug-inetutils] [SCM] GNU Inetutils branch, master, updated. inetutils-1_9_1-36-gb4a938f

[Alfred M. Szmidt]

   >    >    >    +# Prerequisites:
   >    >    >    +#
   >    >    >    +#  * Shell: SVR4 Bourne shell, or newer.
   >    >    >    +#
   >    >    >    +#  * cat(1), expr(1), head(1), kill(1), pwd(1), rm(1).
   >    >    >    +#
   >    >    >    +#  * id(1), grep(1), mktemp(1), ps(1).
   >    >    > 
   >    >    > Is there a reason for these type of comments?  I don't see why
   >    >    > this is useful.
   >    > 
   >    >    Mostly to give a hint to any external tester, in a hope that he or
   >    >    she takes a look at the failing script before filing a bug.
   >    > 
   >    > Wouldn't it be better then to check for this in configure.ac?  Or
   >    > at least assume the same tools as we use in the Makefiles (awk,
   >    > cat, cmp, cp, diff, echo, egrep, expr, false, grep, install-info,
   >    > ln, ls, mkdir, mv, printf, pwd, rm, rmdir, sed, sleep, sort, tar,
   >    > test, touch, tr, true) and only list what is needed over that?
   > 
   >    This is a good point. I have a patch set pending to get rid of
   >    head(1), ps(1), and wc(1), as a starter, so the prerequisite list
   >    you gave as illustration will shrink to "kill(1), id(1),
   >    mktemp(1)". This will improve transparency.
   > 
   > The list above is from the GNU Coding Standards, if you are curious
   > where I got it.
   > 
   >    Are tests in "configure.ac" intended to cover actions in excess of
   >    configuration and build steps? Personally, I view tests as optional
   >    secondary steps for which I do not like the configuration step to
   >    erect any blockers, instead warnings at most. The effort to keep
   >    requisites of tests ajour also in "configure.ac" is slightly more
   >    than we should take upon ourselves.
   > 
   > I was thinking of having configure.ac test for needed programs,
   > and provide a variable that can be used in the test scripts.  For
   > example, if we need kill we could look for that, check that it
   > `behaves' as we'd like, and then simply provide a $(KILL)
   > variable that can be used in the test suite.  And if said
   > variable is not defined, we skip the test, and notify the user.
   > The configure check should of course not cause an error.

   Yes, please! I have begun thinking how I could let the user
   override grep and sed, in particular, so your sketch does exactly
   what I want.

I was really just thinking of something silly like this and have each
test source tools.sh, the tools.sh.in file could be better of course,
i.e. letting the user overide GREP etc.  The checks for programs can
be more exact as well, providing wrappers and what not.  If GREP is
missing, we and FOO test requires it, we can have something like,

  $need_grep || exit 1

In the test case.

diff --git a/configure.ac b/configure.ac
index 017d0ac..5665a16 100644
--- a/configure.ac
+++ b/configure.ac
@@ -137,6 +137,7 @@ AC_PROG_RANLIB
 AC_PROG_YACC
 AC_PROG_LN_S
 AM_MISSING_PROG(HELP2MAN, help2man, $missing_dir)
+AM_MISSING_PROG(GREP, grep, $missing_dir)
 
 gl_INIT
 
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 043e790..0187716 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -67,3 +67,8 @@ endif
 TESTS = $(check_PROGRAMS) $(dist_check_SCRIPTS)
 
 TESTS_ENVIRONMENT = EXEEXT=$(EXEEXT)
+
+tools_subst = sed -e 's,address@hidden@],$(GREP),g'
+tools.sh: tools.sh.in Makefile
+       $(tools_subst) < $(srcdir)/tools.sh.in > tools.sh
+
diff --git a/tests/tools.sh.in b/tests/tools.sh.in
new file mode 100644
index 0000000..53661f7
--- /dev/null
+++ b/tests/tools.sh.in
@@ -0,0 +1 @@
+GREP = @GREP@