Philosophy of how OS API imports are laid out in druntime

Regan Heath regan at netmail.co.nz
Thu Mar 6 01:38:29 PST 2014


On Wed, 05 Mar 2014 17:55:27 -0000, Iain Buclaw <ibuclaw at gdcproject.org>  
wrote:

> On 5 March 2014 17:16, Regan Heath <regan at netmail.co.nz> wrote:
>> On Tue, 04 Mar 2014 00:09:46 -0000, Walter Bright
>> <newshound2 at digitalmars.com> wrote:
>>
>>> This is an important debate going on here:
>>>
>>> https://github.com/D-Programming-Language/druntime/pull/732
>>>
>>> It has a wide impact, and so I'm bringing it up here so everyone can
>>> participate.
>>
>>
>>
>> The disagreement here seems to boil down to two competing goals.
>>
>> 1. Walter wants the C include to map directly to a D import.
>> 2. Sean wants to be able to ensure he does not import and use a platform
>> specific function/definiton in a cross platform application.
>>
>> Is that about right?
>
> 3. Iain wants to be able to ensure ports of druntime (ARM, MIPS,
> SPARC, etc...) are conveniently - as in not complex - split up without
> introducing a new namespace.
>
> :o)

Sorry.  Missed that requirement :)

I like your last idea re transitioning away from core.sys.posix.* by using  
version(Posix).  Presumably, in the case of modules which contain POSIX  
and non-POSIX definition we would wrap those in version blocks also.

I think if we add the mapping modules as Walter suggested then to split  
the runtime for a specific platform (which GCC requires?) then you would  
copy the modules in core.* and core.sys.* and then the  
core.sys.<platform>.*.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/


More information about the Digitalmars-d mailing list