[lldb-dev] Managing Clang and LLVM dependencies systematically

[Vince Harron]

We completely agree that there should be a continuous build with
top-of-everything.

We're looking to *add* a continuous lldb build with the curated versions of
llvm/clang.  I think this will help lldb developers with the signal to
noise ratio.  (Separating their breaks from clang/llvm breaks)  I can
probably get some CPU time for this new build.

Chromium does a similar thing with their multitude of open source
dependencies.  Siva was explaining to me that there is a engineer
"gardener" that updates the working versions file daily (we could do
weekly) by looking for successful "top-of-everything" builds.  The
"gardener" responsibility is handed off in rotation.

Why don't we do this as a trial.  We will setup the hardware (linux at
least) and take responsibility for gardening.  We would like our build
slave to be triggered by the llvm buildbot master.

If there is value in this to the community, we'll expand the gardening
responsibilities.  We can also update the public lldb build instructions to
use the curated build script.

Thanks,

Vince


On Tue, Nov 18, 2014 at 5:10 PM, Zachary Turner <zturner at google.com> wrote:

> Also +1.  I hope to have this going on Windows sometime before the end of
> the year.  Getting ProcessWindows working at least with minimal
> functionality is one of the last major hurdles.
>
>
> On Tue Nov 18 2014 at 5:06:22 PM Kate Stone <katherine_stone at apple.com>
> wrote:
>
>> I've made a point of prioritizing getting our tests to run cleanly here,
>> so it would be a good time for the community to do likewise for other
>> platforms.  Among other benefits, Improving the signal/noise ratio for test
>> failures will make the message to LLVM a lot clearer.
>>
>> Kate Stone k8stone at apple.com
>>  Xcode Runtime Analysis Tools
>>
>> On Nov 18, 2014, at 4:57 PM, Reid Kleckner <rnk at google.com> wrote:
>>
>> On Tue, Nov 18, 2014 at 3:15 PM, <jingham at apple.com> wrote:
>>
>>> 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.
>>>
>>
>> +1, LLDB breakages need to be more visible to Clang/LLVM developers.
>> Currently they are not very visible, mostly for no good reason.
>>
>> Stabilizing the LLDB test suite would help, but the bots could probably
>> be more aggressive about sending IRC or email pings when the build (not
>> tests) fails, as this is the primary way that LLVM and Clang changes break
>> LLDB.
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>


-- 

Vince Harron | Technical Lead Manager | vharron at google.com | 858-442-0868
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141119/72cafa15/attachment.html>