[lldb-dev] Managing Clang and LLVM dependencies systematically

[Siva Chandra]

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