www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - Wiki: How to merge a new DMD release

reply kinke <noone nowhere.com> writes:
I added my workflow to 
https://wiki.dlang.org/LDC_contributor's_guide#Merging_a_new_DMD_release. Let
me know if there are better ways to tackle it, as probably everyone doing it in
the past came up with a scheme of his own.
Apr 18 2018
parent reply Radu <void null.pt> writes:
On Wednesday, 18 April 2018 at 18:18:07 UTC, kinke wrote:
 I added my workflow to 
 https://wiki.dlang.org/LDC_contributor's_guide#Merging_a_new_DMD_release. Let
me know if there are better ways to tackle it, as probably everyone doing it in
the past came up with a scheme of his own.
Experiencing lately some of what this means I realized that there is way to much manual work involved in syncing LDC with mainline. Worse, the merging is done in big chunks and usually requires a expertise on compiler (dmd/ldc), runtime, phobos. I was thinking that a more automated process could make most of that sync a simpler task, at least for phobos and druntime. I envision something like: - Create merge branch with in sync with mainline - Each time a PR is merged in mainline, create a merge PR on LDC side, try to auto-merge it. - If merge fails notify code owners for file/section (similar to code owners in mainline) and the PR author. - Manually fix merge issues, repeat merge step - If merge succeeds, run auto-tester, if tester fails notify owners/author - Fix issues with tests, repeat auto-test - If not issues with test, merge the merge PR - Annotate files/modules that need special attention and should not be auto-merged - Repeat for next mainline release Another bonus is that any issue is know earlier on, no need to wait for next release to realize you missed something for LDC.
Apr 24 2018
parent kinke <kinke libero.it> writes:
Syncing druntime and Phobos is mostly easy-peasy, except 
sometimes for some modules with heavy LDC specifics such as 
std.math and rt.sections.

The bigger problem with auto-sync is that druntime/Phobos and the 
compiler need to be kept in sync, i.e., some druntime patches 
only work after compiler modifications, or (more seldomly) the 
other way around.
That's why we're doing these v2.x => v2.(x+1) steps, that keeps 
the maintenance burden at acceptable levels without having to 
keep up promptly with DMD's pace.

As to merging front-end changes automatically, I think that's 
pretty utopic. It's just one piece of the compiler (with a number 
of LDC specifics and so much potential for merge conflicts in 
refactorings), and a feature such as minimal druntime support is 
something which basically needs to be re-implemented by LDC from 
scratch, as it's almost glue-layer exclusive.

 Another bonus is that any issue is know earlier on, no need to 
 wait for next release to realize you missed something for LDC.
I'm afraid DMD pulls would get stalled even more if they had to additionally worry about LDC.
Apr 25 2018