<div dir="ltr">I think I'm goign to abandon this idea for now. Mostly because I've found a workaround which is a) one line of code and b) only affects windows. So the impact of this workaround is narrower, no risk of messing up any tests which depend on cleaning, and gives more time to come up with a more comprehensive solution, such as something like I and Pavel proposed earlier.</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 26, 2015 at 10:24 AM Todd Fiala <<a href="mailto:todd.fiala@gmail.com">todd.fiala@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Not sure if this is relevant, but I seem to recall the remote test execution would spin off each test method run (test case level, not test suite level) into a new directory. I don't think that would be inherently broken by a no-clean scenario but we'd want to make sure it doesn't break.<div><div><br></div><div>-Todd</div></div></div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 26, 2015 at 7:52 AM, Zachary Turner via lldb-dev <span dir="ltr"><<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I thought of this too and I started prototyping it.<div><br></div><div>The issue that I ran into is that dsym and dwarf tests can all be xfailed, skipped, etc for different reasons, so if there is one method body, you need a way to still define the set of conditions under which dsym and dwarf tests should run, skip, xfail, timeout, etc. </div><div><br></div><div>Do you want to start writing @skipIfDwarfAndOsIsLinuxButCompilerIsNotClang? <span style="line-height:1.5;font-size:13.1999998092651px">Because I know I don't want to deal with the combinatorial explosion of decorators that would result :)</span></div><div><span style="line-height:1.5;font-size:13.1999998092651px"><br></span></div><div><span style="line-height:1.5;font-size:13.1999998092651px">I have some ideas here as well, for example I think we only actually need 1 decorator that we can configure via keyword arguments that can handle arbitrarily complex scenarios of xfailing, debug infos, etc. e.g. @lldb_test(debug_types="dwo,dwarf", xfail = {...}, skip = {...}). </span><span style="font-size:13.1999998092651px;line-height:1.5">But it's all unrelated to the original problem I'm trying to solve. So I think it would be good to design a solution for that, but to do it separately.</span></div><div><span style="line-height:1.5;font-size:13.1999998092651px"><br></span></div><div><span style="line-height:1.5;font-size:13.1999998092651px">The nice thing about just changing the default from clean to not clean is that it's about a 3 line change, has potentially large speed improvements across the board, and also fixes bugs.</span></div><div><br></div><div><br></div></div><div><div><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 26, 2015 at 2:01 AM Pavel Labath <<a href="mailto:labath@google.com" target="_blank">labath@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 26 August 2015 at 06:14, Zachary Turner via lldb-dev<br>
<<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
><br>
> I'll wait and see if anyone can remember which tests rebuild binaries on<br>
> purpose. Otherwise I will try to look through them and see if I can figure<br>
> it out.<br>
<br>
TestInferiorChanged is one that I remember.<br>
<br>
I think this is a good thing to do, but it will need to be done with a<br>
steady hand.<br>
<br>
<br>
<br>
I was also thinking about the dsym/dwo tests.. Instead of basically<br>
having a copy of each test for dwarf and dsym (and soon also dwo), how<br>
about having just one test, and have some higher level logic (the test<br>
runner) know that it needs to execute each test multiple times. The<br>
tests would then just do a buildDefault() (or something) and on the<br>
first run it would build normal dwarf, on the second one dsym, etc. If<br>
we need to run a test only for some combination of debug infos, we<br>
could have @skipIfDsym annotations, like we do for the rest of stuff.<br>
I think this will make what Zachary is proposing easier to do, and it<br>
will make the test writing less awkard.<br>
<br>
<br>
What do you think? I'm ready to chip in on this if we agree to go down<br>
this way...<br>
<br>
pl<br>
</blockquote></div>
</div></div><br></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
</blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
<br></blockquote></div></div><div class="gmail_extra"><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr">-Todd</div></div>
</div></blockquote></div>