<div dir="ltr">Sorry for being late the the party here.<div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 29, 2015 at 9:28 PM, Kamil Rytarowski via lldb-dev <span dir="ltr"><<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<br>
</span><div><div class="h5">On 27.11.2015 00:57, Kamil Rytarowski via lldb-dev wrote:<br>
> On 11/23/15 10:28, Pavel Labath wrote:<br>
>> I believe that for purposes of building distribution packages you<br>
>>  should use the out-of-tree mode of building lldb. This means,<br>
>> you build llvm and clang separately, and then point your LLDB<br>
>> build to their installation path with LLDB_PATH_TO_LLVM_BUILD and<br>
>>  LLDB_PATH_TO_CLANG_BUILD variables. This way you can avoid<br>
>> building llvm/clang twice, you can have a separate package for<br>
>> each logical component of llvm and you can make lldb optional for<br>
>> your users (e.g. have only clang installed normally, if user<br>
>> chooses to install lldb, it will automatically pull in clang if<br>
>> needed). In this mode "make install" should install only the lldb<br>
>> components, which should be correctly linked to the<br>
>> already-installed llvm libraries.<br>
><br>
>> That said, I can't guarantee that this mode will work for you<br>
>> out-of-the-box. We occasionally get patches to fix it up, but I<br>
>> don't know anyone who is using it extensively. However, I think<br>
>> this would be the best way forward for you and I'm prepared yo<br>
>> help you out if you choose to go that way.<br>
><br>
>> What do you think about that?<br>
><br>
>> pl<br>
><br>
><br>
> Thank you for your note on this mode. I was trying to prototype a<br>
> set of packages with: sources of llvm and clang, build dirs of llvm<br>
> and clang and installations of llvm and clang.<br>
><br>
> Badly this approach doesn't work with pkgsrc, as this framework<br>
> contains various checks against using sources, headers, executables<br>
> or other files out of the build tree. Packaging sources and build<br>
> tree triggers errors with moving invalid files into ${DESTDIR}.<br>
> Everything is wolkaroundable, but I think it's not the correct way<br>
> of handling it.<br>
><br>
> I've checked that libcxx, cfe and compiler-rt ship with mechanism<br>
> to build against preinstalled LLVM. I will try them out and I'm<br>
> going to prepare new pkgsrc packages using this approach. Then I<br>
> will try to research doing the same with LLDB, exporting needed<br>
> libraries and headers for the compiler withing llvm and lldb.<br>
<br>
</div></div>For the cross reference.<br>
<br>
A patch allowing to build (tested on NetBSD) out of sources pushed to<br>
review: <a href="http://reviews.llvm.org/D15067" rel="noreferrer" target="_blank">reviews.llvm.org/D15067</a><br>
<span class="">-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2<br>
<br>
</span>iQIcBAEBCAAGBQJWW96JAAoJEEuzCOmwLnZsCLAP/0LrhGlzivOjtykjW3ywvXia<br>
wtZRLYsPwsNBJJERdOGVOJVPovnT02H+Bf1a4eDf0dJXbecklyfiupNfthlvFr9l<br>
PxCLZI4GQPLcP+jqWbhcFRdhzFeyEnLLy0Wjt1MNYG0s3m2u4jJM2ViNLA10/kwS<br>
XX82e2K7q5MUb51MMEJ09ufpYyGff7XmjVE78w1ekfNSRlKFMc0DNBsaIx4oKZfM<br>
G2IUtRNL59ad2pkw/xA3D2OPtoTk7+a2jjF8Z4nYY6kUSyBPUlCYrjyfavVCreR6<br>
6Zo2E3lkkEb6PSIfb57RlMtxBIfmIBjv5w6OcFjSK6aYvffY9IMgyBJvGbdA+Ee7<br>
DlCFZax25eJPglEnfzAI2XOHOUQJtDwhb45N+XWshLfUax2e52KJvj9nq9J8pOse<br>
AC00qRQN+KTZsil43dlOfEn5m18mJ9o+CohK5eLMoTnS9QdtP8OEv72zGjOsSqrx<br>
vXDx01ziuQRCgsJ+niZXHgRLA65hxD5XgSGEBzr5prRLtU6q6V/HpYOsC46+pySc<br>
ibLrRWHnaeBVJknwz11iBo4gBZRk3lGhi5aTfu9+kcX6ylKSn2nn34+HGHr//FZi<br>
SrKcb3z7WikAR0c9cHBNOnwbro6o08j8zUE2l2S08risLRDDu01KBo3yFebjHz8D<br>
vQqFJNDkRLywQbXezcjB<br>
=7C7K<br>
<div class="HOEnZb"><div class="h5">-----END PGP SIGNATURE-----<br>
_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">-Todd</div></div>
</div>