RE: Question on --test-name=NAME

[Arthur Schwarz]

(thanks by the way)


> On 26 April 2015 at 18:39, Arthur Schwarz <address@hidden> wrote:
> > Now for the case you mentioned in identifying a program, which is 
> > really a test case renamed in the manual for mystifying and unknowable 
> > reasons. Well, there is no mechanism for "The first non-option 
> > argument passed to the test driver is the program to be run, and all 
> > the following ones are command-line options and arguments for this
program." Let's go through some of options.
> >
> > Suppose command line arguments are input on the command line (seems 
> > reasonable huh).
> 
> I think you are wrong there. When it says command-line, it means a command
line in a Makefile recipe. You will see it by looking at any Makefile.in
generated from a Makefile.am with tests. It will look
> like:
> 
> t/file.sh.log: t/file.sh
>         @p='t/file.sh'; \
>         b='t/file.sh'; \
>         $(am__check_pre) $(LOG_DRIVER) --test-name "$$f" \
>         --log-file $$b.log --trs-file $$b.trs \
>         $(am__common_driver_flags) $(AM_LOG_DRIVER_FLAGS)
> $(LOG_DRIVER_FLAGS) -- $(LOG_COMPILE) \
>         "$$tst" $(AM_TESTS_FD_REDIRECT)
> 
> You can see the command-line options like --test-name etc.

Now this (almost) makes sense. Let me see here. The "command line input" is
not a command line input, it is a test driver option input via Makefile.am
something. Now I don't understand automake/Makefile.am/make well enough to
even begin to interpret your example, but the manual provides no guidance
and for me, that's the point. I can follow directions. There are no
directions.

As a point, 15.3.3.1 Command-line arguments for test drivers shows all
options as having the syntax "--option=value". Your example does not have
this syntax. Will your example work? Should this be in the manual, as in
"--option[=| ]value?"

By the way, you have "@p='t/file.sh'" and --test-name "$$f". Do you mean
--test-name "$$p"?

>  
> 
> > Oh, about the example. The automake variable can't be used for 
> > anything but scripts, see 15 Support for test suites "The other (and 
> > most used) form is based on the use of generic test scripts, and its 
> > activation is triggered by the definition of the special TESTS 
> > variable." This quite clearly says that anytime that a TESTS variable 
> > is seen then generic scripts are used. But the example has "TESTS = 
> > foo.pl bar.py baz" which are not generic scripts. It must mean that 
> > the test driver is a generic script, but oh wait. The test drivers are 
> > for PERL and PYTHON and scripts. And (last time I looked) PERL and
PYTHON were not generic scripts.
> 
> They could be run the same way as shell scripts, as long as they have the
right "#!" header.

A test case as given in TEST=testcase, can be an executable program, not a
script. The documentation is still faulty although I should have been
clearer.

   TEST_EXTENSION = address@hidden
   @EXEEXT_LOG_DRIVER= ...

I suppose can be used to define an executable program (which can not be
converted into a script).

It should be clear that I do not have extensive experience in constructing
make scripts. But I can read. What I am trying to do is run a blasted test.
I rely exclusively on the documentation. The documentation seems not to
provide direction so I am forced to scrutinize each sentence to determine
its meaning. As a student in reading a text book I saw "... and the rest is
left as an exercise to the student." This is not a text book, it is a
manual. I expect things not to be left as an exercise.