I would like that we begin a Druntime stub project. The purpose of the project is to.

Separate D library specific code and OS specific code.
Create an empty stub that can be compiled and where OS customization can be use as a starting point. You simply copy the stub directory and start from there.
Create a common "interface" to druntime.
People who have custom systems will have less of a merge hell when the code is separated.

In several posts I've seen that people are looking for a druntime with limited support for certain embedded systems, so there is a demand for a stub despite it is more or less unusable in its pure form. Also another reason I want to make a stub is that creating this runtime abstract interface is that as soon you start to mess around in the OS specific code, the risk of breaking the existing OS support is obvious. Better to have a gradual approach to this. Creating a stub will be require quite a lot of work by itself. After the stub has been created, it should be agreed upon that existing OS support should gradually move to the druntime interface approach and no new OS specific code should be added in the generic parts in druntime.

One approach that was suggested was as described in this post.

https://forum.dlang.org/post/r4rcdg$222f$1@digitalmars.com

which import files based on compile time identifiers.

If we take the file druntime/src/core/sync/semaphore.d

a file would be added at druntime/src/core/sys/stub/semaphore.d

where "stub" is really OS identifier.

The current semaphore.d file would be changed to the following.


import config.osconfiguration;

...
	
	// Semaphore
	//
	// void wait();
	// void notify();
	// bool tryWait();
	////////////////////////////////////////////////////////////////////////////////
version(druntimeAbstract)
	mixin(import_("core", "sys", osname, "semaphore"));
}
else
{
	/**
	 * This class represents a general counting semaphore as concieved by Edsger
	 * Dijkstra.  As per Mesa type monitors however, "signal" has been replaced
	 * with "notify" to indicate that control is not transferred to the waiter when
	 * a notification is sent.
	 */
	class Semaphore
	{
		////////////////////////////////////////////////////////////////////////////
		// Initialization
		////////////////////////////////////////////////////////////////////////////


		/**

where osname = stub in the case. osname comes from a configuration file that are imported almost everywhere. Not sure where this should be located though.


Tell me what you think in the comments below.

On Friday, 13 November 2020 at 12:47:18 UTC, IGotD- wrote:

>
> where osname = stub in the case. osname comes from a configuration file that are imported almost everywhere. Not sure where this should be located though.
>
>
> Tell me what you think in the comments below.

I am an advocate of creating a separate implict hierarchy (like "system.*") that content will be attached (included) by the build system depending on the build target. It's simpler and clearer.

By the way, before starting of rework like discussed it is need to go through the entire code and complete "version(Posix){...} else version(Windows){...}" branches by "else static assert(OSisNotSupportedMsg);". Otherwise we are doomed to very interesting glitches.

On Wednesday, 18 November 2020 at 15:28:36 UTC, Denis Feklushkin wrote:
>
> I am an advocate of creating a separate implict hierarchy (like "system.*") that content will be attached (included) by the build system depending on the build target. It's simpler and clearer.
>
> By the way, before starting of rework like discussed it is need to go through the entire code and complete "version(Posix){...} else version(Windows){...}" branches by "else static assert(OSisNotSupportedMsg);". Otherwise we are doomed to very interesting glitches.

We already have a "sys" folder in druntime, is that what you mean. Also we need both that the build system compiles the system specific files as well as importing based on system.

My plan is to only add version(druntimeAbstract), then hopefully we will not intrude on the existing OS implementation. version(druntimeAbstract) must be the first choice as a Posix operating system might choose that instead of druntimeAbstract when it is set.

On Friday, 20 November 2020 at 11:33:26 UTC, IGotD- wrote:
> On Wednesday, 18 November 2020 at 15:28:36 UTC, Denis Feklushkin wrote:
>>
>> I am an advocate of creating a separate implict hierarchy (like "system.*") that content will be attached (included) by the build system depending on the build target. It's simpler and clearer.
>>
>> By the way, before starting of rework like discussed it is need to go through the entire code and complete "version(Posix){...} else version(Windows){...}" branches by "else static assert(OSisNotSupportedMsg);". Otherwise we are doomed to very interesting glitches.
>
> We already have a "sys" folder in druntime, is that what you mean.

No. I'm talking about a directory that will only be defined implictly at compile time for a specific target platform.