<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 --- - test infra: consider storing and re-using test inferior build artifacts for a given test directory"
href="https://llvm.org/bugs/show_bug.cgi?id=30295">30295</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>test infra: consider storing and re-using test inferior build artifacts for a given test directory
</td>
</tr>
<tr>
<th>Product</th>
<td>lldb
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>All Bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>lldb-dev@lists.llvm.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>todd.fiala@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>As brought up in llvm.org/pr30271
(<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - TestGdbRemoteExitCode.py tests fail on some builders"
href="show_bug.cgi?id=30271">https://llvm.org/bugs/show_bug.cgi?id=30271</a>):
Pavel had the idea of re-using build artifacts across test methods and test
files in a given test directory. This likely would increase the speed with
which we could run the test suite as it eliminates the need to rebuild test
inferiors for any test that includes more than one test method.
My further comments from pr30271:
====8<====
<span class="quote">> We could achieve a big speedup by just not re-building the binaries over and over again.</span >
I could see that being a really big win.
We'd have to parameterize the memoization of the built artifacts by anything
that could change. These would include:
* make command line
* environment variables
I think that already covers the compilers, as they would be specified by CC/CXX
env vars or command line parameters to make.
We'd need a concept of the build artifacts for a given set of build settings.
We could conceivably allow these to be stored in a specified directory, which
could allow builders to preserve them across clean builds of the lldb product
if we so desired. (We might not want that, so that a clean build is really a
clean build of the test artifacts as well). We could figure out that later.
I think this is a very worthwhile item to investigate.
I don't know if/how this impacts what we would do if we used lit to run our
tests. (As I mentioned on a different thread, I have not yet put any effort
into looking at what our test suite would look like running existing tests in
that test runner. We currently have a number of assumptions about how our
build process interacts with test method runs that may or may not fit into the
lit expectations as they currently stand. Zach mentioned we could write some
kind of test runner that plugs into lit, which maybe can handle these details.
In that case, the effort for your suggestion could be easily lifted and used in
both scenarios, and therefore wouldn't be a waste of effort if we switched test
runners).
====8<====</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>