|
From: | Jacob Bachmeyer |
Subject: | Re: Documenting test script arguments and revising runtest_file_p |
Date: | Sat, 12 Jan 2019 00:05:14 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.22) Gecko/20090807 MultiZilla/1.8.3.4e SeaMonkey/1.1.17 Mnenhy/0.7.6.0 |
Ben Elliston wrote:
On Fri, Jan 11, 2019 at 10:38:05PM -0600, Jacob Bachmeyer wrote:Is the contents of the "runtests" variable part of the DejaGnu API currently? The variable is not documented and runtest_file_p exists to abstract its meaning.No. It should only be procs. We should be providing accessor procs for any variables, ideally.
The "testsuite file" command provides this for the *dir variables, but the "testsuite" multiplex call is intended for commands relating to the testsuite as a whole (another one on my TODO list is "testsuite depend" or "testsuite depends" for tracking dependencies not directly visible to the framework).
I have been trying to make a distinction between "testsuite options" and "test run options". Essentially, a "testsuite option" is something related to the code in a testsuite and simply setting it probably will not work or be useful in general. The "MULTIPASS" variable is an example of a testsuite option, as would be a future "API level" declaration. A "test run option" is something that users can more-or-less freely set, like --verbose or the name of a compiler binary to use.
In this model, the "testsuite" command should probably stick to "testsuite options", although "testsuite file" indirectly accesses the *dir variables, which are "test run options", so the question then becomes what to name the new API call. I will start with offering "testsuite script args" defined to return what is currently the second element in $runtests. If we also want the first element of $runtests (and that is not entirely redundant to [info script] or we want it anyway), I suggest "testsuite script name" for that purpose.
Comments? -- Jacob
[Prev in Thread] | Current Thread | [Next in Thread] |