[lldb-dev] Exclusively build and install LLDB?

[Pavel Labath via lldb-dev]

On 2 December 2015 at 16:19, Todd Fiala <todd.fiala at gmail.com> wrote:
> Sorry for being late the the party here.
>
> Sean Callanan and some of the other members can comment more on this, but
> LLDB's expression parser for C/C++ is going to need access to the clang
> include headers, so somehow lldb has to be able to find them.  Out of tree
> llvm/clang usage is certainly possible as others have pointed out.  Using
> that as the one way it is done, though, is likely to lead to pain.  Parts of
> lldb's source will adjust as needed when the API surface area of LLVM or
> clang changes.  It may not be happening quite as frequently as it had say 2
> or 3 years ago, but it definitely happens.  So my expectation would be that
> if you decouple lldb from llvm/clang (i.e. let them drift), sooner or later
> you will get bitten by that.  Particularly when things like clang modules
> and whatnot come along and actually require different logic on the lldb side
> to deal with content generated on the clang/llvm side.  Once expression
> evaluation is potentially compromised (due to the drift), I suspect the lldb
> experience will degrade significantly.

I think you have misunderstood our intentions here.

Kamil, correct me if I am wrong, but I don't think we are talking
about building lldb against a different version of clang. What we want
is just to be able to build and link lldb against an already-built
clang (of the same version). This is quite useful when you (as a
distribution maintainer) want to provide prebuilt packages. So, for
example you can have a "clang" and an "lldb" package. Users wishing to
install clang, just get the first one, while someone installing lldb
will get the correct clang package pulled automatically. I believe the
easiest way to build these packages is to use the standalone mode of
lldb (which already exists, and some people use that).

hope that makes sense,
pl