Philosophy of how OS API imports are laid out in druntime

[Regan Heath]

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?


To clarify some points..

@Walter are you asking for ALL includes even #include <windows.h> to map?   
OR, are you asking for only those headers thought to be "cross platform"  
headers to map?

For example, <sys/ioctl.h> is not a windows header and would not be  
considered "cross platform".

I have the following include folders in Visual Studio 2008:
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include        -  
posix, c[++] std library headers
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\include -  
ATL/MFC headers
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include          -  
windows specific headers

would you only expect to map headers from the first of those, and not the  
rest?

That first folder contains 184 files which correlate to posix, and c[++]  
standard library headers.


@Sean to achieve your ends you are currently importing core.sys.posix.*  
right?  So, any modules added to core.* would not affect you?  I presume  
the modules in core.sys.* are cut down versions of the headers in  
core.sys.linux etc with any the platform specific definitions removed, yes?


So, if we currently have the following layout:

[the root folders]
core\stdc
core\sync
core\sys

[the platform specific tree]
core\sys\freebsd
core\sys\freebsd\sys
core\sys\linux
core\sys\linux\sys
core\sys\osx
core\sys\osx\mach
core\sys\windows

[the posix tree]
core\sys\posix
core\sys\posix\arpa
core\sys\posix\net
core\sys\posix\netinet
core\sys\posix\sys

Note; I think that "sys" folder in core is unnecessary and may be causing  
some confusion.  Why not have a "c" folder to separate the C modules from  
other core components.  I mean, why isn't stdc in sys?

So, anyway, could we not simply add modules as Walter described to core.*  
and core.sys.* to map to the specific platform and header for the build  
system?  Likewise we would want to map core.* to core.stdc.* where  
appropriate.

It seems this will satisfy Walter without impacting Sean.. other than  
being loads of "unnecessary" modules from your perspective.

R

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