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

[Mats Erik Andersson]

söndag den 26 februari 2012 klockan 16:07 skrev Alfred M. Szmidt detta:
>    >    > 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.

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.

Best regards,
  Mats