[lldb-dev] Exclusively build and install LLDB?

Kamil Rytarowski via lldb-dev lldb-dev at lists.llvm.org
Thu Dec 3 16:30:30 PST 2015

Hash: SHA256

Compatibility with wide range of LLVM or Clang releases is out of scope.

On 02.12.2015 17:38, Todd Fiala wrote:
> Yes, that concept came out in the thread.  I just wanted to make
> sure there wasn't also a desire to park on a version of llvm/clang,
> and if so, that the path there is not pleasant and definitely not
> intended to be supported on top of tree svn/trunk.
> Thanks for clarifying!
> -Todd
> On Wed, Dec 2, 2015 at 8:34 AM, Pavel Labath <labath at google.com 
> <mailto:labath at google.com>> wrote:
> On 2 December 2015 at 16:19, Todd Fiala <todd.fiala at gmail.com 
> <mailto: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
> -- -Todd

Version: GnuPG v2


More information about the lldb-dev mailing list