Ben Elliston wrote:
On Sat, Dec 29, 2018 at 11:40:32PM -0600, Jacob Bachmeyer wrote
This patch is the long-promised dejagnu-report-card(1) tool,
although it is not yet actually installed under that name, instead
being run as "dejagnu report card" or "dejagnu report-card".
The former ("dejagnu report card") is confusing because "card" looks
like an argument. I think the launcher subcommands should not contain
spaces. dejagnu report-card seems natural enough to me.
The "dejagnu report card" form is an alias as long as there is no
"report" command -- the launcher sees "report", notes that "report" is
not a valid command, appends the next argument, checks again, and finds
that "report-card" is valid. If invoked as "dejagnu report-card", the
launcher sees "report-card", notes that that *is* a valid command, and
runs with it.
This is for user convenience, along with the symlink-to-launcher
feature, which is intended to bring the commands into the $PATH where
Readline can find them. There are some CLIs that make extensive use of
multi-word commands (C-Kermit is a good example, complete with command
completion; this model is also very common in networking equipment) and
the space bar can be easier to hit than the "-" key.
That said, the dejagnu subcommands need canonical names for
documentation. Should those be like "dejagnu-report-card" (using a
launcher symlink) or "dejagnu report-card" (standard name for launcher,
explicit full name for command)?
Or should the Texinfo manual use "dejagnu report-card" and the man pages
use "dejagnu-report-card"? The man pages themselves must use the latter
form for their own names for technical reasons, but can list any form in
the NAME section.
All three implementations are included in this patch. Installing it
as dejagnu-report-card simply requires making a symlink
dejagnu-report-card -> dejagnu; the launcher will handle the rest if
called via such a symlink.
As the person who gets to maintain this code, I'm really not a fan of
multiple implementations. I don't mind if it's sh, Tcl or AWK. I
understand the intrinsic value of n-version development in testing,
but in practice, I don't want multiple copies of the code that do the
same thing. Please just pick one on the criteria of performance or
maintainability and submit that, please.
Picking just one and throwing out the other code is hard, but at least
the other versions will be in the mailing list archive now, so that
makes it easier. :-)
Are you sure about this, since that value in testing is an ongoing
benefit with future maintenance (and also a cost in additional effort to
make changes, which may outweigh that benefit)?
I will look into it, but if you insist, I am leaning towards the Awk
version: (1) it has the best performance (by a significant margin) in
every test I have done so far, and (2) Awk is part of the POSIX baseline
and the GNU Coding Standards permit even configure itself (and Makefile
rules) to assume the availability of awk(1) without checking or fallback.
Please tell me if you insist on this -- there is also some scaffolding
in the testsuite in this patch that supports multiple implementations
and needs to be reworked if multi-implementation commands are to be avoided.
-- Jacob
_______________________________________________
DejaGnu mailing list
DejaGnu@gnu.org
https://lists.gnu.org/mailman/listinfo/dejagnu
