auto-tester breakage

Iain Buclaw ibuclaw at gdcproject.org
Mon Nov 25 15:00:46 PST 2013


On 25 November 2013 20:34, Iain Buclaw <ibuclaw at gdcproject.org> wrote:
> On 25 November 2013 19:35, Brad Roberts <braddr at puremagic.com> wrote:
>> On 11/25/13 2:35 AM, Iain Buclaw wrote:
>>>
>>> On 25 November 2013 10:32, Iain Buclaw <ibuclaw at gdcproject.org> wrote:
>>>>
>>>>
>>>> Yep, there's been some middle-end changes.  Sorry, next time I'll give
>>>> you heads up.
>>>>
>>>> ...Which, incidentally, might come very soon, as there are some other
>>>> front-end breaking changes in the pipeline with a new wide-int.h
>>>> header.
>>>>
>>>
>>>
>>> And the last GDC change has been untested (so far).
>>
>>
>> Well, if you're not worried that the build/tests are broken, I probably
>> shouldn't be either, but I am pondering on ways of increasing the visibility
>> of the state of the system.  The only 'no work to be done' state is a
>> healthy green master branch.  I'm considering adding a once every X days
>> (daily, weekly, etc) status summary email with what open work there is to be
>> done (broken master, open pulls, etc).
>>
>> I don't consider it right for master branches to be in a broken state, ever.
>> But I don't own the code under test, so it's not up to me. :)
>>
>
> It's a kind of special case thing.  I'm currently doing this 2.064
> merge in small steps (just taking a monthly development snapshot and
> working my way up because to merge the entire amount of changes is too
> much to track down breakages).  So it's merge, push, run testsuite,
> get things stable, repeat at the moment, and will be until 2.064 merge
> is complete.

Testsuite should be passing now on latest gdc head and gcc snapshots.
Until the next D frontend merge gets done sometime tomorrow.


More information about the D.gnu mailing list