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

[Alfred M. Szmidt]

   >    > Keep up the good work Mats!
   >    > 
   >    >    +# 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.