> > 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.
