[lldb-dev] Managing Clang and LLVM dependencies systematically

[jingham at apple.com]

I actually think it is good that incompatible changes to llvm break the lldb build bots right away.  Then they will get fixed in lldb right after the change was made when it is clear in people's minds what just went on.  So I wouldn't want to add any of this sort of machinery to lldb's build w.r.t. the build bots.  Now that the build-bots are running regularly, the clang folks can also see the breakage right away and just fix it, which they often do (thanks for that BTW...)  So if there were a "GOOD_LLVM" it should not be used for the build-bots.

I'm also leery of fixing on "stable good versions of llvm/clang" for use in lldb for any length of time, since any subtle bugs that get introduced on the llvm/clang side will get to mix with other subtle bugs and incidental changes and make themselves more complex to detangle when we get around to pulling in the llvm/clang changes.  So again, I would urge folks really working on lldb not to use the "last good clang" for very long, since those are the people who will see this early.

I can see the advantage of this for "casual lldb developers".  Are there enough of them to warrant putting this in?

Jim


> On Nov 18, 2014, at 2:53 PM, Siva Chandra <sivachandra at google.com> wrote:
> 
> Hello,
> 
> I am essentially an outsider here but thought I would put down some
> ideas about how to "fix" (so to say) the dependency on LLVM and Clang.
> The aim here is to shield LLDB from build breakages introduced due to
> API changes in LLVM and Clang. This is not to say that LLDB should not
> take in the latest and greatest Clang/LLVM, but only that such a thing
> should be managed more systematically (by not breaking LLDB builds
> without notice).
> 
> [The assumption I am making here is that managing the dependency on
> LLVM and Clang is the responsibility of the LLDB project. Correct me
> if I am wrong. If it in fact is the responsibility of LLVM/Clang, then
> just ignore the rest of this mail. Also, its very likely that an
> equivalent approach was already discussed. In which case, kindly point
> me to it.]
> 
> The approach I have in mind is outlined as a bunch of steps:
> 
> 1. Let the official way to build LLDB be via a script called
> build_lldb(.py) living in lldb/scripts/.
> 
> 2. This script should have something like this:
>    LAST_GOOD_LLVM_SHA = <git sha>
>    LAST_GOOD_CLANG_SHA = <git sha>
>    LAST_GOOD_LLVM_REV = <svn rev>
>    LAST_GOOD_CLANG_REV = <svn rev>
>    [To keep it simple, I will only outline Git related process henceforth.]
> 
> 3. build_lldb is really simple. Before actually building, it syncs
> LLVM and Clang to LAST_GOOD_LLVM_SHA and LAST_GOOD_CLANG_SHA
> respectively. There are the shas which are known work for LLDB ToT.
> 
> 4. When and why should LAST_GOOD_LLVM_SHA and LAST_GOOD_CLANG_SHA be updated:
> i) To bring in the latest and greatest of either or both of them.
>    a) A newer version of Clang/LLVM could be providing a new feature which
>    LLDB would like to use. In such a case, the last good shas should be updated
>    in the same patch that uses the new feature in LLDB.
>    b) A newer version of Clang/LLVM could just be doing some API adjustments.
>    In such a case, the last good shas should be updated in the same patch that
>    adjusts for the new API in LLDB.
> ii) When adding a feature to LLVM/Clang to be used in LLDB. This is essentially
>    similar to point (a) from above. For such cases, the feature to LLVM/Clang
>    should be added first. Then, the corresponding shas should be updated in the
>    same patch that uses the new features in LLDB.
> 
> The benefits the above approach brings are:
> 1. Developers working only on LLDB don't get hit by breaking Clang/LLVM changes.
> 2. Bisecting will be a lot easier now as it is all just one repo in LLDB's view.
> 
> There are downsides ofcourse to this approach:
> 1. It introduces a process (hence, a burden) wrt managing the dependencies.
> 2. It will require regular updates to the last good shas (even if LLDB
> has nothing to gain from them).
> 
> In my view though, the benefits outweigh the burdens.
> 
> Thanks,
> Siva Chandra
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev