That seems fair. It would be great to have some higher level mechanism to
generate runs of the tests that only differ by how the target programs are
built. For instance, if some day we ever get serious about optimized code
debugging (suppresses giggle) it would be good to run the test suite on
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
compr
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.
-Todd
O
I thought of this too and I started prototyping it.
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,
On 26 August 2015 at 06:14, Zachary Turner via lldb-dev
wrote:
>
> I'll wait and see if anyone can remember which tests rebuild binaries on
> purpose. Otherwise I will try to look through them and see if I can figure
> it out.
TestInferiorChanged is one that I remember.
I think this is a good t
The first and second issues (cleaning once at startup, switching between
dsym and dwarf tests) can probably both be solved at the same time by
having the test runner sort the runs and do all dsym tests first, and then
all dwarf tests, and having TestBase do make clean once before each of
those step
It is fairly common practice (at least it is for me) when figuring out why a
test failed, or adding to a test case, or when looking for a good example file
to poke at, etc, to go to some relevant test directory, do a "make" then poke
around a bunch. I don't generally remember to clean when I'm
Another possibility is changing the arguments to buildDwarf and buildDsym.
Currently they take a clean argument with a default value of True. Does
this really need to be True? If this were False by default it could
drastically speed up the test suite. And I can't think of a reason why
make clean
