Hi!

I propose to discuss a possibility of reorganizing code by this way:

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

(druntime/impl contains directories what named like most frequently used versions names)

Platform will be switched on tag-based by build script without "branches of branches" inside of code. I.e., if we build for a wide available Debian Linux for x86 it would be 3 tags: linux+glibc+x86, and for module core/sys/posix/setjmp.d these directories will be used:

druntime/impl/x86/core/sys/posix/-no-file-
druntime/impl/glibc/core/sys/posix/setjmp.d <- this will be used
druntime/impl/linux/core/sys/posix/-no-file-

(Obviously, except default, only one file must be found - otherwise this is error condition)

You should remember: not all modules are so complex as setjmp.d, most files will be in default directory (and many will not be in druntime/impl hierarchy at all). And, also, druntime is a special sort of software and this approach will help to maintain duplicated nature of druntime's bindings.

This approach will force us to avoid difficult branching schemas and to separate common logic and OS- or arch- related stuff

It opens ability to import modules with foreign data structures on non-native OSes: it will be possible to remove module "guards" like "version (Linux):" at start of modules and your Windows app will be able to import Linux data structures

This approach also helps to add new platforms (most important for me)

On Tuesday, 14 November 2023 at 00:33:34 UTC, Denis Feklushkin wrote:

Be warned, this has a very long history and ulti ended up nowhere.

https://issues.dlang.org/show_bug.cgi?id=11666

https://github.com/dlang/druntime/pull/1255
https://github.com/dlang/druntime/pull/744
https://github.com/dlang/druntime/pull/741
https://github.com/dlang/druntime/pull/731

On Tuesday, 14 November 2023 at 06:04:27 UTC, Iain Buclaw wrote:

Forgot to add to the potential benefits list:

Proposed approach eliminates tons of these identical lines:

version (AArch64) version = ARM_Any;
version (ARM)     version = ARM_Any;
[...]
version (X86)     version = X86_Any;
version (X86_64)  version = X86_Any;

version (OSX)
    version = Darwin;
else version (iOS)
    version = Darwin;
else version (TVOS)
    version = Darwin;
else version (WatchOS)
    version = Darwin;

Yes! And I suggested something similar too - https://forum.dlang.org/thread/rwmqulighwecqyxqbnkt@forum.dlang.org

This all suggests that something needs to be done with the existing approach. For example, for more than 10 years we haven't seen the expected creation of "lightweight druntime" for embedded. No one was able to solve such static branches puzzle gracefully.

By the way, proposed here "tags+directories" solution is the full equivalent of currently used "version branching"? (Can anyone refute this proposition?)

On Tuesday, 14 November 2023 at 11:48:00 UTC, Denis Feklushkin wrote:

Proof of concept: https://github.com/dlang/dmd/pull/15822

On Tuesday, 14 November 2023 at 00:33:34 UTC, Denis Feklushkin wrote:

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.

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?

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.

First thing is that we need version strings in imports. This has been suggested for years but nothing has happened. If we add this, then modularizing druntime will fall more naturally (and perhaps their own projects too).

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

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

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.

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

On Thursday, 16 November 2023 at 17:13:37 UTC, Denis Feklushkin wrote:

I made update of the proposal description text, https://github.com/dlang/dmd/pull/15822

On Sunday, 19 November 2023 at 19:53:53 UTC, Denis Feklushkin wrote:

Not sure If I'm going to reply here or on github.

First, I think that you need to more precisely explain what a "tag" is. What is the underlying data type and how does it differ from a version identifier. I don't understand what a tag is by reading the PR.

The PR doesn't mention anything about the generic part of the implementation. Where should the generic part be?

Also how the source code hierarchy, how would it look like?

Let's take really small example like setjmp.d and show how it should be implemented, both inside the file and where the files should located.

On Monday, 20 November 2023 at 13:39:21 UTC, IGotD- wrote:

Doesn't matter. Sorry for a response delay, I was away

Okay, I'll write here and when everything is discussed I’ll add it to the PR description

Proposed tags are similar to a D's versions, but I decided to separate its name because tags become not corresponding to a built-in D versions, at least.

For example, most likely, tags with names like “posix_compatible_threads” will appear, because in the future we will understand that some OSes use Posix interace API to provide threads functionality but while not being a Posix system. The same goes for working with files, etc.

I also suggest to write sets of tags for each target in this form:

x86_64,posix,osx

and not in:

x86_64-posix-osx

to prevent attempts to combine proposed druntime tags with compiler target triplets

I don’t understand what is meant by "generic part" here

All tags-driven code will be placed into druntime/config/ directory

Inside of config/ each tag provides it's own files hierarchy corresponding to main druntime modules hierarchy.

For example, file:

druntime/config/posix/core/sync/event.d

will be used as module "core.sync.event" if "posix" tag choised

For now, all *.d files involved into discussed PR is a such examples

On Friday, 1 December 2023 at 05:29:31 UTC, Denis Feklushkin wrote:

Most importantly, new name need to avoid confusion. If we call them "version", we will inevitably begin to confuse it with D versions.

"Tags" (in various uses in the different software) are a similar scheme. Therefore, I think the name fits well.