On 11/15/2011 03:40 PM, Iain Buclaw wrote:
On 15 November 2011 23:21, dsimcha<dsim...@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).
