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.

On Tuesday, 4 March 2014 at 00:09:47 UTC, Walter Bright 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.

You mean the debate about copyright notices :o)

On Tuesday, 4 March 2014 at 00:09:47 UTC, Walter Bright 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.

I think the current debate is more a result of miscommunication
than disagreement.  Or at least I hope it is, as I simply don't
understand your perspective here.  For those who haven't seen it
yet, the subject of the discussion is where the D version of C
header files currently in core.stdc and core.sys.* should live
and how they should be exposed to users.  I came up with the
current design and so I obviously favor the status quo, and I
stand by my original reasons for the design (explained in the
thread).

On 3/4/2014 7:53 AM, Craig Dillabaugh wrote:
> On Tuesday, 4 March 2014 at 00:09:47 UTC, Walter Bright 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.
>
> You mean the debate about copyright notices :o)

No, see Sean's post.

On Tuesday, 4 March 2014 at 00:09:47 UTC, Walter Bright 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.

So, if we combine your, Sean's and yebblies' proposals, we will have
1) ports folder with implementation subfolders for each os and their translated headers - this works better with your "copy what I need" use case - just copy your os's folder and you can work, you can't copy what you need if headers for the same os are spread across many folders.
2) public module core.stdc will conditionally import ports.os.* for platform-specific definitions compliant with C standard
3) public module core.sys.windows - it may depend on stdc and thus import ports.windows.*
4) public module core.sys.posix - for everything else, which corresponds to headers seen in unixes and conditionally imports ports.os.*, it may have a folder for windows for things like unistd if those didn't fall under stdc.
5) we probably shouldn't have cocoa and gtk?

On Wednesday, 5 March 2014 at 10:37:03 UTC, Kagamin wrote:
> 2) public module core.stdc will conditionally import ports.os.* for platform-specific definitions compliant with C standard
or ports.glibc, ports.msvcrt, ports.snn, ports.bionic for different c libraries.

On Tue, 04 Mar 2014 00:09:46 -0000, Walter Bright <newshound2@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/

On 5 March 2014 17:16, Regan Heath <regan@netmail.co.nz> wrote:
> On Tue, 04 Mar 2014 00:09:46 -0000, Walter Bright <newshound2@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)

On Tuesday, 4 March 2014 at 20:50:40 UTC, Sean Kelly wrote:
> On Tuesday, 4 March 2014 at 00:09:47 UTC, Walter Bright 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.
>
> I think the current debate is more a result of miscommunication
> than disagreement.  Or at least I hope it is, as I simply don't
> understand your perspective here.  For those who haven't seen it
> yet, the subject of the discussion is where the D version of C
> header files currently in core.stdc and core.sys.* should live
> and how they should be exposed to users.  I came up with the
> current design and so I obviously favor the status quo, and I
> stand by my original reasons for the design (explained in the
> thread).

I agree with "complexmath" POV too.

PS: By the way, look at the issue number (11666). Well 666 so of
course it would generate some disagreement. :)

Matheus.

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

> On 5 March 2014 17:16, Regan Heath <regan@netmail.co.nz> wrote:
>> On Tue, 04 Mar 2014 00:09:46 -0000, Walter Bright
>> <newshound2@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/