[lldb-dev] Managing Clang and LLVM dependencies systematically

[Siva Chandra]

On Tue, Nov 18, 2014 at 3:15 PM,  <jingham at apple.com> wrote:
> I can see the advantage of this for "casual lldb developers".  Are there enough of them to warrant putting this in?

If it is not made official, then there is no onus to maintain it, and
hence would eventually fall out of use and bitrot.

I take it that you prefer Clang/LLVM changes leading to LLDB breakages
be seen immediately.

>> On Nov 18, 2014, at 2:53 PM, Siva Chandra <sivachandra at google.com> wrote:
>> 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
>