On Monday, 6 January 2014 at 17:04:57 UTC, Sean Kelly wrote:
On Monday, 9 April 2012 at 10:19:47 UTC, Iain Buclaw wrote:
Personally I feel that people porting to specific
architectures should maintain their differences in separate
files under a /ports directory structure - lets say
core.stdc.stdio as a cod example. The version for bionic would
be under /ports/bionic/core/stdc/stdio.d, and that is the
module that gets compiled into the library when building for
bionic. When installing, the build process generates a header
file of the bionic version of core.stdc.stdio and puts the
file in the correct /include/core/stdc/stdio.di location.
This would really be fine. I'd even say just put them in
core.sys.bionic or whatever, except that this location is for
platform-specific imports and so core.sys.bionic.stdio could
contain nonstandard extensions, while anything exposed by
core.stdc should not. For all of these issues, bugzilla
tickets and/or pull requests are much appreciated. I know that
the design I chose for my own ease of maintenance may not scale
past the handful of platforms DMD targets.
I would submit tickets requests for these things, but in order to
create a meaningful ticket that can be acted upon, one must know
precisely what should be done, and articulate that in the ticket.
But in order to understand what must be done, one must
understand the current organization of the runtime. But in order
to understand the current organization of the runtime, one needs
to be able to see the abstraction. But the crux of this problem
is that one can't see the abstraction because of the way the
runtime is organized (catch 22).
The same goes for pull requests.
Those already familiar with the runtime could accelerate
contribution from others by 1) documenting the current
abstraction on the wiki or 2) following up on
https://d.puremagic.com/issues/show_bug.cgi?id=11666 so one can
see the abstraction. Finally the original runtime authors and
porters could both begin writing a porting guide.
