[Lldb-commits] [PATCH] D12899: cmake fixups: post-build python step dependency and lldb-server dependency for lldb on Linux

Todd Fiala via lldb-commits lldb-commits at lists.llvm.org
Fri Sep 18 09:41:49 PDT 2015


tfiala added a comment.

>From a high level, when we ask a build system to build the lldb executable, we want that to mean "build me an lldb and anything it will use as part of its normal operation."

If we did not build the lldb executable's expected components (as was the case when I started this), we would have:

- no python support copied over.  Surprise!  If we don't do this, we actually fall back to using the system-installed python lldb libraries, out of sync with the lldb binary just built, and significant issues will ensue as lldb with python-enabled *will* pick up an LLDB python module from somewhere.  (This was fixed when I made the python library post-build step dependent on lldb, which by a purist "'only build me exactly what I asked for, and assume I know every bit of what is needed at all times" approach.  And this was really hit).

- no lldb-server.  Oops - lldb doesn't actually work to debug anything.  Do you know what to put on the command line to get it to work?  Do we want users to have to know all that?

I do see the point of view of being pure and saying "give me only what I want."  But being pure can mean "hey, you only asked for the lldb driver, so don't build the lldb core content that goes in a .so."  That starts getting absurd --- we clearly are saying at some point "when you say lldb, you mean give me the internal details needed for this to really work."

I was for not including lldb-server on platforms where it isn't needed right now (which was pretty much anywhere except Linux AFAICT), because then you incur extra build time for something that you might not need --- lldb works fine without lldb-server on some platforms (Darwin, FreeBSD, maybe others).  But where it is needed for proper lldb operation, not building it is asking our users to know more about the internal organization of the execution than I think we should be trying to take on.


http://reviews.llvm.org/D12899





More information about the lldb-commits mailing list