[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

dejagnu(1) subcommand namespace planning

From: Jacob Bachmeyer
Subject: dejagnu(1) subcommand namespace planning
Date: Mon, 31 Dec 2018 20:27:59 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090807 MultiZilla/ SeaMonkey/1.1.17 Mnenhy/

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]