== Quote from Brad Roberts (bra...@slice-2.puremagic.com)'s article > On Fri, 8 Jul 2011, Iain Buclaw wrote: > > == Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article > > > On 2011-07-08 10:42, bioinfornatics wrote: > > > > @sean > > > > if you install ldc2 like: > > > > $ cmake . -DD_VERSION:STRING=2 -DCONF_INST_DIR:PATH=/etc > > > > $ make -j4 VERBOSE=2 > > > > $ make -j4 install > > > > > > > > and try install druntime from > > > > https://github.com/D-Programming-Language/druntime.git I can't because > > > > make file is only for dmd. What i try to said, yes we need 1 druntime so > > > > for this reason druntime installer need support at least dmd, ldc, gdc. > > > > But is not case currently. And for this reason d2 can't go to Fedora 16. > > > > Because ldc2 use cmake for build 3 projects (ldc, druntime, phobos) > > > > I need 3 installer separately. And ldc2 use a druntime fork! > > > > > > > > thanks for any answer :-) > > > I believe that it's _expected_ that other compilers will use forks of > > > druntime. They may have to make changes to druntime to work, and Sean > > > doesn't > > > want to have to maintain all of the differences for every compiler. > > > Rather, > > > druntime is the reference implementation intended for dmd, and other > > > compiler > > > maintainers do whatever they need to with their own version of it to get > > > it > > > work with their compiler. > > > - Jonathan M Davis > > > > Exactly this, and the case is also vice versa with gdc. The druntime > > reference > > library also does many things that are unreasonable and incompatible with > > gdc (and > > I assume ditto ldc too). > > > > One future plan on my list is the restructuring of core/stdc to be more > > ports > > friendly (the source, not the installed files) - something to help push > > along ARM > > development for D2 with GDC, and hopefully for other archs to follow > > pursuit. The > > result being one elongated patch that won't be accepted upstream for sure. > > :~) > > > > Regards > > Iain > This is one area that I disagree with Sean on. I think it's worth merging > in as much as we can to the druntime code base. I'm not against having > separate trees vended by each compiler, but I hope/expect those to be the > lowest level details and not be detectably different from phobos or user > code. Having core.stdc diverge, as just one example, is a recipe for > having code that only works on top of one specific runtime, which is NOT > what we want.
Hardly - as core.stdc (forgot core.sys too :) is just a wrapper for the standard C library. Sweet story short, having version() else version() else version() for 6+ platforms and 12+ architectures is not workable in a single managed file - consider, for example, sys.stat with 15 variants of struct stat_t inside. Regards Iain