The patch I recently submitted to add dejagnu-report-card led to an
interesting issue that I had not considered: command namespace planning
for the various dejagnu(1) subcommands.
Originally, very little thought had actually been put into this, and the
launcher features related to this handling were arrived at mostly by
implementation. The idea that "report-card" and "report card" should be
synonymous came early, as an extension of the idea that the launcher
should recognize a command name embedded into a symlink pointing to
itself. The broader principle was that the launcher should chain
together as many words as needed to form a command, or accept such a
chain prepackaged, even into $0.
Ben raised an issue, paraphrased here as: with this feature and a
"report-card"/"report card" command, what happens if a future "report"
command is added?
While discussing this, I arrived at what I believe to be the best
solution: The "report card"/"report-card" command introduces an implied
"report" command that takes a fixed parameter as its first argument:
the report type. The first report type supported is thus "card".
This model would mean that the spaced version is the canonical name, and
no actual command may be a word-wise prefix of another command.
Applying this to the planned "canned test stub" feature leads to an
implicit "add" command of the form "add <what>", with implementations
for adding empty testsuites, tools to existing testsuites, and possibly
test groups to existing (tool, testsuite) pairs. ("add test-group"
amounts to "mkdir") Most commands would not include dashes in their
canonical names, with "add test-group" nicely highlighting the actual
rule as an exception to the general rule: "test-group" is logically a
single term, like "tool" and "testsuite".
-- Jacob
_______________________________________________
DejaGnu mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/dejagnu
