On 2 December 2015 at 16:19, Todd Fiala <todd.fi...@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 _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
