[lldb-dev] [RFC] Removing lldb-mi

Raphael “Teemperor” Isemann via lldb-dev lldb-dev at lists.llvm.org
Fri Jul 19 11:41:29 PDT 2019


The expected way as of now is to compile lldb-mi against an installed lldb (either a compiled version or whatever your OS/package manager provides). The CMake file will automatically find LLDB and build against it. See the travis CI script[1] in the repo on how that looks in practice.

The problem with the tests is that:

1. They (randomly) fail, which is why we already disabled most (all?) of them even before we removed lldb-mi. That’s mostly because of lldb-mi bugs and the way the tests were implemented from what I understand.
2. They depend on the LLDB python testing logic which isn’t as trivial to port over to the standalone lldb-mi repo. And the testing logic also not distributed with LLDB.

So after some discussion we decided that we don’t port the tests over as it’s just not worth it. The ideal outcome would be that someone writes a new set of tests that are is stable than the ones we had.

- Raphael

[1] https://github.com/lldb-tools/lldb-mi/blob/master/ci/travis.sh


> On Jul 19, 2019, at 6:34 PM, Ted Woodward <tedwood at quicinc.com> wrote:
> 
> As of yesterday, lldb-mi has been removed from lldb and moved to https://github.com/lldb-tools/lldb-mi <https://github.com/lldb-tools/lldb-mi> .
>  
> Some questions:
> Is the expected way to build lldb-mi to drop the lldb-tools/lldb-mi repo into <lldb>/tools/lldb-mi?
> The lldb-mi tests weren’t moved into the new repo on github. Do we plan on moving them?
> If we don’t move them, do we just rely on the lldb-mi executable not existing to keep from trying to run them?
> If we do move them, how do we run them?
>  
> Ted
>  
> From: lldb-dev <lldb-dev-bounces at lists.llvm.org> On Behalf Of Jonas Devlieghere via lldb-dev
> Sent: Friday, July 5, 2019 11:44 AM
> To: Raphael “Teemperor” Isemann <teemperor at gmail.com>
> Cc: LLDB <lldb-dev at lists.llvm.org>
> Subject: [EXT] Re: [lldb-dev] [RFC] Removing lldb-mi
>  
> Thank you for doing this, Raphael. I believe this shows that it's possible to keep lldb-mi alive, without today's maintenance burden on the LLDB community, a solution that seems to appease everyones concerns in this thread. I hope this sparks interest for somebody to step up as a maintainer. 
>  
> I went ahead and created a diff to add the proposed deprecations to the LLVM release notes: https://reviews.llvm.org/D64254 <https://reviews.llvm.org/D64254> 
> I'll put up another diff to remove the code, which we can land once LLVM 9 has branched. 
>  
> Thank you,
> Jonas
>  
> On Thu, Jul 4, 2019 at 12:24 PM Raphael “Teemperor” Isemann via lldb-dev <lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>> wrote:
> I just went forward with this and made a quick test repo with an out-of-tree lldb-mi that compiles against the system LLDB:https://github.com/Teemperor/lldb-mi <https://github.com/Teemperor/lldb-mi> This seems to work fine with the exception of the python tests which require LLDB’s python code for testing which isn’t installed alongside LLDB. I guess we will have to see if we copy the related test code there or we just rewrite the test suite (which is anyway broken). On the upside, we can now just use Travis for CI as we don’t have to compile LLVM/Clang/LLDB, so that’s nice.
>  
> I’m in favor of deprecating lldb-mi with 9.0.0 and then we can give downstream time until 10.0.0 (or X.0.0 :) ) to package out-of-tree lldb-mi for users. Given how simple lldb-mi is, this seems like a reasonable timeframe.
>  
> - Raphael
>  
>  
> On Jul 4, 2019, at 9:51 AM, Davide Italiano via lldb-dev <lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>> wrote:
>  
>  
>  
> On Thu, Jul 4, 2019 at 12:58 AM Zdenek Prikryl via lldb-dev <lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>> wrote:
> We're using it with Eclipse and Eclipse based product, so I'd like to keep as well! :-)...
> 
> Zdenek
> 
>  
> I do understand that there's desire from people to keep this around (from an user perspective), but I guess this fundamentally misses Jonas' original mail point.
> lldb-mi has been unmaintained for a long time (at least the past two years from what I can tell), and we tried to use it in emacs without success.
> It has never been a priority for many of the parties putting effort in lldb and I'm under the impression the situation won't change in the foreseeable future.
> Unless somebody steps up as maintainer I don't think there's a lot of future for the tool. 
> Maybe a good compromise would be that of having lldb-mi living in a separate repo somewhere on GitHub, as it only uses the SBAPI, which is public and set in stone?
>  
> --
> Davide
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
>  
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20190719/a852ab0d/attachment-0001.html>


More information about the lldb-dev mailing list