<div dir="ltr">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.<div><br></div><div>Thanks for clarifying!</div><div><br></div><div>-Todd</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 2, 2015 at 8:34 AM, Pavel Labath <span dir="ltr"><<a href="mailto:labath@google.com" target="_blank">labath@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2 December 2015 at 16:19, Todd Fiala <<a href="mailto:todd.fiala@gmail.com">todd.fiala@gmail.com</a>> wrote:<br>
> Sorry for being late the the party here.<br>
><br>
> Sean Callanan and some of the other members can comment more on this, but<br>
> LLDB's expression parser for C/C++ is going to need access to the clang<br>
> include headers, so somehow lldb has to be able to find them.  Out of tree<br>
> llvm/clang usage is certainly possible as others have pointed out.  Using<br>
> that as the one way it is done, though, is likely to lead to pain.  Parts of<br>
> lldb's source will adjust as needed when the API surface area of LLVM or<br>
> clang changes.  It may not be happening quite as frequently as it had say 2<br>
> or 3 years ago, but it definitely happens.  So my expectation would be that<br>
> if you decouple lldb from llvm/clang (i.e. let them drift), sooner or later<br>
> you will get bitten by that.  Particularly when things like clang modules<br>
> and whatnot come along and actually require different logic on the lldb side<br>
> to deal with content generated on the clang/llvm side.  Once expression<br>
> evaluation is potentially compromised (due to the drift), I suspect the lldb<br>
> experience will degrade significantly.<br>
<br>
</span>I think you have misunderstood our intentions here.<br>
<br>
Kamil, correct me if I am wrong, but I don't think we are talking<br>
about building lldb against a different version of clang. What we want<br>
is just to be able to build and link lldb against an already-built<br>
clang (of the same version). This is quite useful when you (as a<br>
distribution maintainer) want to provide prebuilt packages. So, for<br>
example you can have a "clang" and an "lldb" package. Users wishing to<br>
install clang, just get the first one, while someone installing lldb<br>
will get the correct clang package pulled automatically. I believe the<br>
easiest way to build these packages is to use the standalone mode of<br>
lldb (which already exists, and some people use that).<br>
<br>
hope that makes sense,<br>
pl<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">-Todd</div></div>
</div>