A recent change for the LLDB community are buildbots for Linux using clang<http://lab.llvm.org:8011/builders/lldb-x86_64-debian-clang> and gcc<http://lab.llvm.org:8011/builders/lldb-x86_64-linux>. This has been a quiet change and I suspect that the status isn’t being monitored by most of the community. Consistent with llvm and clang, I’d like to make the case for working together to keep the buildbots green. Specifically, to build the case for a policy to fix or revert commits that break the Linux buildbots.
First, test coverage is getting much closer to Darwin<http://lldb.llvm.org/status.html> for the x86-64 targets using clang and gcc. In addition, the test decorators for skipOnLinux, expectedFailureLinux and expectedFailureGcc are cross-referenced with bugzilla tickets<http://llvm.org/bugs/buglist.cgi?product=lldb&component=All%20Bugs&resolution=---&list_id=34925> (i.e. to help distinguish between new failures and known failures). As the new buildbots trigger on llvm, clang and lldb commits, they provide a useful tool to root cause regressions when llvm/clang is out of step with lldb (i.e. changes to DWARF or AST record layout). Historically these have been time-consuming problems that affect many tests at once. Given monitoring and community support, these improvements make it possible to encourage adoption of Linux LLDB packages on Debian, Ubuntu<http://llvm.ecranbleu.org/>, Arch and Solus. As the current packages are built from trunk, stability is a current barrier to adoption. This point also suggests the need for wider pre-commit testing of common code on Linux. In turn, we would also benefit from a stable Darwin buildbot<http://lab.llvm.org:8011/builders/lldb-x86_64-darwin11>. Thoughts? - Ashok Thirumurthi Intel of Canada
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
