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 <tedw...@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-boun...@lists.llvm.org> On Behalf Of Jonas > Devlieghere via lldb-dev > Sent: Friday, July 5, 2019 11:44 AM > To: Raphael “Teemperor” Isemann <teempe...@gmail.com> > Cc: LLDB <lldb-dev@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@lists.llvm.org <mailto:lldb-dev@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@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>> wrote: > > > > On Thu, Jul 4, 2019 at 12:58 AM Zdenek Prikryl via lldb-dev > <lldb-dev@lists.llvm.org <mailto:lldb-dev@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@lists.llvm.org <mailto:lldb-dev@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@lists.llvm.org <mailto:lldb-dev@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@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
