On Wed, Jan 17, 2018 at 12:32 PM, Adrian Prantl via lldb-dev <lldb-dev@lists.llvm.org> wrote: > Hi lldb-dev! > > I've been investigating some spurious LLDB test suite failures on > http://green.lab.llvm.org/green/ that had to do with build artifacts from > previous runs lying around in the test directories and this prompted me to > ask a couple of general noob questions about the LLDB testsuite. > > My understanding is that all execution tests are compiled using using `make` > in-tree. I.e.: the test driver (dotest.py) effectively executes something > equivalent to `cd $srcdir/packages/.../mytest && make`. And it does this in a > serial fashion for all configurations (dwarf, dSYM, dwo, ...) and relies on > the `clean` target to be implemented correctly. > > I don't understand all the design decisions that went into the LLDB > testsuite, but my naive intuition tells me that this is sub-optimal (because > of the serialization of the configurations) and dangerous (because it relies > on make clean being implemented correctly). It seems to me that a better > approach would be to create a separate build directory for each test variant > and then invoke something like `cd $builddir/test/mytest.dwarf && make -C > $srcdir/packages/.../mytest`. This way all configurations can build in > parallel, and we can simply nuke the build directory afterwards and this way > get rid of all custom implementations of the `clean` target. >
I think this is a much better strategy. FWIW, I wouldn't object if you want to switch to cmake entirely as LLVM is using it as its only true build system, but that seems a much larger change. In any case, whatever gets decided, happy to help you with that. -- Davide _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
