<html>
<head>
<base href="https://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - Allow 'lit' driver to cooperate with test formats and suites to add options (or at least sanitize accepted params)"
href="https://llvm.org/bugs/show_bug.cgi?id=30668">30668</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Allow 'lit' driver to cooperate with test formats and suites to add options (or at least sanitize accepted params)
</td>
</tr>
<tr>
<th>Product</th>
<td>Test Suite
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>lit
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>modocache@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>daniel@zuster.org, llvm-bugs@lists.llvm.org
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>(This task was copied from
<a href="https://reviews.llvm.org/diffusion/L/browse/llvm/tags/RELEASE_390/final/utils/lit/TODO">https://reviews.llvm.org/diffusion/L/browse/llvm/tags/RELEASE_390/final/utils/lit/TODO</a>.
It was originally written by Daniel Dunbar.)
We have started to use the --params method more and more extensively, and it is
cumbersome and error prone. Additionally, there are currently various options
``lit`` honors that should more correctly be specified as belonging to the
ShTest test format.
It would be really nice if we could allow test formats and test suites to add
their own options to be parsed. The difficulty here, of course, is that we
don't know what test formats or test suites are in use until we have parsed the
input specifiers. For test formats we could ostensibly require all the possible
formats to be registered in order to have options, but for test suites we would
certainly have to load the suite before we can query it for what options it
understands.
That leaves us with the following options:
* Currently we could almost get away with parsing the input specifiers without
having done option parsing first (the exception is ``--config-prefix``) but
that isn't a very extensible design.
* We could make a distinction in the command line syntax for test format and
test suite options. For example, we could require something like::
lit -j 1 -sv input-specifier -- --some-format-option
which would be relatively easy to implement with optparser (I think).
* We could allow fully interspersed arguments by first extracting the options
lit knows about and parsing them, then dispatching the remainder to the
formats. This seems the most convenient for users, who are unlikely to care
about (or even be aware of) the distinction between the generic lit
infrastructure and format or suite specific options.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>