Created attachment 417
LDC2 support for druntime
I have attached a patch which adds support for ldc2 to druntime. To build use ./build-ldc.sh in the src/ directory. I created a shell script for it as I find the current make system is far too complicated, feel free to port it to use make though. Note that ldc2 is still largely a work in progress. I have also moved gc/basic/*.d to gc/basic/gc/*.d, purely because ldc plays nicer this way. You will need to update the dmd make files to reflect this change.
Comment #1 by hoganmeier — 2010-02-05T09:19:31Z
What's the status of this issue, Sean?
Comment #2 by sean — 2010-02-05T11:36:59Z
The druntime source tree has changed to the point where it's no longer trivial to integrate an additional compiler runtime. I'll have to think about how to add LDC2 support.
Comment #3 by hoganmeier — 2010-02-05T12:04:44Z
Yeah, I think gdc is also gradually approaching 2.020 where druntime was introduced and will face the same problem.
They are currently upgrading to 2.016.
Comment #4 by sean — 2010-02-09T09:46:41Z
The correct approach may be to have a separate Druntime for each compiler. This is a bit less granular than the previous design where multiple compiler runtimes could be plugged into the same SVN tree, but that design was a pain to deal with from a maintenance perspective (though it's still functionally feasible). I don't really like that it would mean code merges for the GC and core code however. Suggestions welcome.
Comment #5 by braddr — 2010-02-09T11:04:04Z
A separate runtime per compiler seems very wrong to me.
I can understand that the current code bases look fairly far apart due to the length of time they've been allowed to drift, but really, shouldn't they be very very similar for the vast majority of the code?
I recognize that ldc has introduced additional compiler emited function calls, but there's no reason that those can't be included in druntime.
Comment #6 by hoganmeier — 2010-02-09T12:54:20Z
Couldn't those parts that are compiler-specific be held in their own subfolders or whatever to keep it clean?
Comment #7 by sean — 2010-02-09T17:45:04Z
They were in their own folder, in fact, there was a 'compiler' folder with subfolders for each compiler, but the structure was deemed unnecessarily complicated when the only compiler supported was DMD.
Comment #8 by sean — 2010-02-09T17:50:28Z
For what it's worth, part of the problem is that the path to a module must correspond to the package name. This makes the SVN structure a lot more complicated when there are two compiler runtimes that both have to live in "rt.*", for example.
Comment #9 by doob — 2010-06-30T12:49:14Z
Why not just use the approach Tango uses?
Comment #10 by sean — 2010-06-30T22:42:56Z
Druntime used to, but it's a very complicated structure. And even the Tango runtime was intended to originally provide only a template. The hope was that compiler writers would eventually each maintain their own runtime, and it doesn't really make sense that every compiler runtime would live in the same SVN.
Comment #11 by dsimcha — 2010-07-16T10:13:21Z
(In reply to comment #3)
> Yeah, I think gdc is also gradually approaching 2.020 where druntime was
> introduced and will face the same problem.
> They are currently upgrading to 2.016.
As of today, they are at 2.019. (http://bitbucket.org/goshawk/gdc/changesets/) Perhaps this should be up-prioritized because I assume it's going to be a blocker of further progress.