Continuous Merging For GDC and LDC?

[Alex Rønne Petersen]

On 16-11-2011 00:40, Iain Buclaw wrote:
> On 15 November 2011 23:21, dsimcha<dsimcha at yahoo.com>  wrote:
>> How does the merging process for new Phobos/druntime/DMD front ends work
>> w.r.t. GDC and LDC?  To what extent is it automated?  If it's mostly
>> automated except when things go wrong (or could be made so), we should set
>> up a server somewhere (maybe on one of the DMD tester boxes that's
>> underworked, if there is one) that automatically merges every commit to
>> druntime/phobos/dmd and tests it.
>>
>> It seems to take agonizingly long after every DMD release for LDC and GDC to
>> get caught up, which makes sense only if the merges are being done by hand
>> or changes are made to low-level stuff (certain parts of druntime, the glue
>> layer of the compiler, etc.).  Furthermore, such continuous merging might
>> encourage DMD/Phobos/druntime devs to do things in a more LDC/GDC-friendly
>> way and would make trunk revisions of Phobos/druntime/dmd in between
>> releases available to GDC/LDC users.
>>
>
> API changes in the D frontend could break builds. New features in D
> that require backend support could break builds.  The only positive to
> continuous merging is that they will be caught early and dealt with.
>
>
> Other than that, I tend to use merges as a time to start merging in
> some experimental features I've got in the flux.  In this current
> merge I've been working out support for named value return support in
> gdc, and weeding out some bugs present in the current in/out contract
> inheritance.
>
>

One thing that confuses me a bit is why GDC and LDC need downstream 
copies of druntime/phobos. Couldn't patches that fix the libraries for 
certain archs/OSs be sent upstream, in order to reduce merging work and 
always provide the latest release to users? Now that so many version 
identifiers are standardized across DMD, GDC, LDC, and SDC, I think it'd 
be beneficial to do this.

- Alex