[Dlang-internal] druntime: proposed changes in code organization

[Denis Feklushkin]

On Thursday, 16 November 2023 at 15:13:44 UTC, IGotD- wrote:

>> For example, druntime/src/core/sys/posix/setjmp.d file 
>> contains few version branches of libc and OSes versions. It 
>> can be reorganized as:
>>
>> druntime/impl/arm/core/sys/posix/-no-file-
>> druntime/impl/x86/core/sys/posix/-no-file-
>> druntime/impl/netbsd/core/sys/posix/setjmp.d
>> druntime/impl/openbsd/core/sys/posix/setjmp.d
>> druntime/impl/linux/core/sys/posix/-no-file-
>> druntime/impl/glibc/core/sys/posix/setjmp.d
>> druntime/impl/default/core/sys/posix/setjmp.d
>>
>
> I suggested this a while ago that druntime should be refactored 
> to files instead of the version hell like #ifdef hell in C. 
> However, in order this to properly work was that import should 
> be able to use version strings in the filename path.

If I understand you, this is ~same approach as I implementing

> Also, one question in the example. Why two files
>
> druntime/impl/arm/core/sys/posix/-no-file-
> druntime/impl/x86/core/sys/posix/-no-file-
>
> as I assume these are stubs. Isn't a stub no OS at all?

No, there is only for illustration what this dirs isn't contain 
file setjmp.d. These directories can contain another files, of 
course

If you ask about "no-OS environment" supporting, then, in my 
opinion, at the druntime level it is not make sense to discuss 
about this: if you implement needed calls then druntime will work 
in this environment. Briefly, "No-OS" - is just a kind of OS type.

> Apart from that. I strongly support having stubbed versions in 
> druntime, also with more fine granularity which would be great 
> for embedded systems. Some systems have file systems but no 
> process support for example.

I believe that such  granularity will formed naturally if the 
code is reorganized in the proposed way

And I think processes (threads?) are necessary part of the D 
language. Even on MCUs: the fact is that threads are involved 
into the garbage collection process