tfiala added a comment. So at this point, it looks like we're just missing a mechanism to check for gmodules support, and then add it to the supported_categories list if it is available.
I'll have a look a that. This might be the time where we want to break out an apple-clang vs. llvm.org-clang when we talk about version numbers. We're asking for trouble when we treat both as the same, yet they have drastically different version numbers that will eventually collide as llvm.org version numbers increase. ================ Comment at: packages/Python/lldbsuite/test/lldbtest.py:1488 @@ +1487,3 @@ + @wraps(attrvalue) + def dwarf_test_method(self, attrvalue=attrvalue): + self.debug_info = "gmodules" ---------------- labath wrote: > Shouldn't this be `gmodules_test_method`? I agree with @labath ================ Comment at: packages/Python/lldbsuite/test/plugins/builder_base.py:144 @@ -143,1 +143,3 @@ +def buildDwarf(sender=None, architecture=None, compiler=None, dictionary=None, clean=True): + """Build the binaries with dwarf debug info.""" ---------------- labath wrote: > shouldn't this be `buildModules` or something? buildGModules() sounds right here, particularly since it matches the define being passed in. And adjust the comment below to reflect. http://reviews.llvm.org/D19998 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
