[lldb-dev] Exclusively build and install LLDB?

Thu Dec 3 16:30:30 PST 2015

-----BEGIN PGP SIGNED MESSAGE-----
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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWYN6jAAoJEEuzCOmwLnZsdnsQAK7bn22uT/O61/QDF9oEYRlR
pzZtSkmGQZQuizw+TVUGgApk/KmwZ8BFsXUhguDzuDx8AR4qblYR+VwHSsQCaZwe
OIoZFTOOsmw5fBsbcYmtjlGsWOFQBWXOpMwXIZ5eQyQU8Q1rW2ssmniyfO7SkIE8
agcfzShyhzkFsQ9SLlHkZbNP+CALBVCOGWH4PnvdSkruIHKxmoOycgNvsG1HXsOV
jtgsx7S4EK1WEjPg3yzIiTgpYJVS2q3C2tLXmuYIg0TsNCwtoutSgodx6AV6Z31X
RbuDU8Gr4HqGZZa8LydRmoj2FRrkaMYEO2b8L9caQDRDCyn0TVEb6m5GSzut9EjP
+BKqeiNLaNVHIXjabsRf7a7tWpVSF0RH2vtyJOlXX1fisca4gWgpzLHY0u6IB37K
LnA4H1j/+f4ffOc1UpjFZs9Y6aTKLwAZaieZQXz8cRMueTpFBegla2osvY/Stg2f
OZnhzeUGcPVN2aERtR+HHxqWAZKHPHIPeTQTZ9vAEGF/KpedVrMEjgICCbisnLgQ
VNnm68m1aD8+30DNI70629JdmyjLGr5khzBmPipNqqZk8TB9Wn5HExTcSQod3fBP
+NHsaeucVcR0ZXL7vXM88yN28PRyHTGnVItAkSunsVCHwJ4WKtUyCHouSR2SMD2W
g0MvEbC3BKaPKRYB3WgB
=PHHJ
-----END PGP SIGNATURE-----