www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Druntime stub project

reply IGotD- <nise nise.com> writes:
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.
Nov 13 2020
parent reply Denis Feklushkin <feklushkin.denis gmail.com> writes:
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.
Nov 18 2020
parent reply IGotD- <nise nise.com> writes:
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.
Nov 20 2020
parent Denis Feklushkin <feklushkin.denis gmail.com> writes:
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.
Nov 20 2020