On 2011-07-09 01:29, Iain Buclaw wrote:
== 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
How about having a separate branch for each compiler in druntime? The
compiler maintainers will maintain their own branch but if there's a
change that doesn't actually affect any compiler specific code, i.e.
adding a new function to core.stdc, then that change can be made to all
branches.
--
/Jacob Carlborg
