[D-runtime] Supporting different C libraries and architectures
Martin Nowak
dawg at dawgfoto.de
Sun Feb 26 15:09:21 PST 2012
On Sun, 26 Feb 2012 21:30:33 +0100, Brad Roberts <braddr at puremagic.com>
wrote:
> It's not much less of a problem for DMD than any other compiler given
> that many, if not all, of the same problems crop
> between windows, linux, freebsd, and osx -- even if they are all x86 at
> the moment. Only one of those is a glibc based
> platform. Among the non-windows platforms, all of them strive for some
> level of posix compatibility. The major
> differences are more "what subset of posix" not "I did big parts of the
> posix apis differently". I believe that
> exposing completely separate trees for each combination of platform and
> libc implementation is likely to lead to major
> pain down the road. For what it's worth, I'm not extrapolating based
> purely on dmd's current state. I've worked with
> nearly every flavor of unix at one point in time or another, porting
> large code bases among them.
>
> I do agree that parts of druntime (and almost certainly phobos too)
> conflate issues and use the occasional api that
> isn't part of posix. Those are more the exception than the rule and are
> likely fairly easy to clean up. The classic
> example is indeed backtrace. It's use is both non-portable (though man
> it's a nice api to have) across libc's but also
> very well isolated to one call back function. Additionally, where it
> doesn't exist, it almost certainly would be better
> to implement behind a similarly named function call rather than a
> version block per platform right there in the
> exception handling code.
>
> My 2 cents,
> Brad
>
I agree, keeping different trees in sync will create more issues than
fixing the few functions.
More information about the D-runtime
mailing list