www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Continuous Merging For GDC and LDC?

reply dsimcha <dsimcha yahoo.com> writes:
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.
Nov 15 2011
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 15 November 2011 23:21, dsimcha <dsimcha yahoo.com> wrote:

 How does the merging process for new Phobos/druntime/DMD front ends work
 w.r.t. GDC and LDC? =A0To what extent is it automated? =A0If it's mostly
 automated except when things go wrong (or could be made so), we should se=


t

 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 han=


d

 or changes are made to low-level stuff (certain parts of druntime, the gl=


ue

 layer of the compiler, etc.). =A0Furthermore, such continuous merging mig=


ht

 encourage DMD/Phobos/druntime devs to do things in a more LDC/GDC-friendl=


y

 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.


--=20
Iain Buclaw

*(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Nov 15 2011
next sibling parent bcs <bcs example.com> writes:
On 11/15/2011 03:40 PM, Iain Buclaw wrote:

 On 15 November 2011 23:21, dsimcha<dsimcha 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.


It seems to me that there would be some value in this proposal. If 
nothing else it could start with the most up-to-date hand merged 
instance is available, branch (is that the correct term?) from it, go as 
far as it can from that and generate a pull request for the maintainers 
to consider. If it can merge cleanly from the DMD trunk and the test 
situation doesn't regress, It's likely correct (and if it isn't then the 
test suite is lacking :) and if it's not correct, it has likely done a 
lot of the boring work.

Having that available would provide something like "nightly" builds to 
the people who want that and it would provide as much automation as the 
maintainers want to get from it (after all, it would be madness to allow 
such a system to actual muck with the official branch).
Nov 15 2011
prev sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 16-11-2011 00:40, Iain Buclaw wrote:

 On 15 November 2011 23:21, dsimcha<dsimcha 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
Nov 16 2011
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, November 16, 2011 10:28:37 Alex R=C3=B8nne Petersen wrote=
:

 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 fo=


r

 certain archs/OSs be sent upstream, in order to reduce merging work a=


nd

 always provide the latest release to users? Now that so many version
 identifiers are standardized across DMD, GDC, LDC, and SDC, I think i=


t'd

 be beneficial to do this.


druntime is expected to have differing versions per compiler. Both Sean=
 Kelly=20
and Iain Buclaw would argue that - they have in the past. However, I wo=
uld=20
certainly hope that that would _not_ be the case with Phobos. It's supp=
osed to=20
be at a higher level and thus should generally be able to avoid such is=
sues.

- Jonathan M Davis
Nov 16 2011