Even in this exact case we have the multiple variants situation.  If we use the substitutions method we would reduce the test coverage by half, which doesn’t seem like a good idea. <br><br>Similarly, in the target variables tests i added to the native pdb plugin Jim was asking if I could also enable that exact same test for other platforms.  But it’s not possible without a way to run multiple variants.  And for tests where no running process is required I think it’s a worthy goal to try to do that.<br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 29, 2018 at 6:04 AM Pavel Labath <<a href="mailto:pavel@labath.sk">pavel@labath.sk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 26/10/18 18:34, Zachary Turner wrote:<br>
> I was thinking about this some more and I’m not sure simple<br>
> substitutions will suffice.<br>
> <br>
> We can provide substitutions to abstract away the command line, but that<br>
> doesn’t doesn’t really address the issue that we still need to have a<br>
> way to then run the the test program with each of the build outputs. <br>
> Keep in mind that it might take more than one compiler and/or linker<br>
> invocation to generate an output, and more than one lldb-test invocation<br>
> for the checks.<br>
> <br>
> The best idea I have for now is to split the check file into a common<br>
> file that everyone can share, but the lldb-test lines can be copied.  So<br>
> there is one .test file for windows, one for non windows, each with only<br>
> RUN lines, both sharing a common check file.<br>
> <br>
> I don’t think we should block this patch on coming up with something<br>
> more complicated than this though <br>
> <br>
<br>
The substitutions won't help if you're planning to run multiple variants<br>
of the same test (e.g. a DWARF and a PDB version) on all hosts. However,<br>
if you always just want to run a single version of the test (e.g., for<br>
the host), then it's enough to have a substitution which builds the<br>
given version of the executable.<br>
<br>
Given how the memory map tests are implemented right now (they require a<br>
running process, and they don't care too much about the details of how<br>
the debugee was built), this should be sufficient. I don't think we will<br>
ever have two flavours of these tests run in the same instance of the<br>
test suite, as it would require us the specify how to launch and debug<br>
an executable on multiple hosts.<br>
<br>
So, I'd recommend to stick with the substitution idea until we come up<br>
with something better.<br>
<br>
pl<br>
</blockquote></div>