druntime redesign

[IGotD-]

On Sunday, 15 March 2020 at 10:29:11 UTC, Denis Feklushkin wrote:
> On Tuesday, 25 February 2020 at 01:21:33 UTC, Denis Feklushkin 
> wrote:
>
> Probably I seem to know easiest way:
>
> Many modules are scattered by version() keywords that implement 
> common calls necessary when using any platform.
> For brief example look into: core/sync/event.d
>
> We can improve Makefiles (and cmake in case of LDC fork of 
> druntime) to include only needed platform-dependend subdirs 
> what will contain these modules but without "versions", just 
> code for each supported platform.
> (Do not confuse with core.sys.platform_name section!)
>
> (And I couldn’t do it myself right now because I don’t know 
> well enough make and cmake systems. I am need "initial sample 
> template" to do things like in it.)
>
> After such replacement it will be very easy to clear out 
> remaining libc calls (if it will be need - all supported 
> platforms actually have libc interfaces), and also support for 
> new arbitrary platforms will be ready - for supporting any new 
> platform will be enough to replace platform-specific section 
> with your own at build stage by build system.
>
> What do you think about this? Is that good idea?

If take src/core/sync/semaphore.d (class Semaphore) for example 
this is an example with a lot of version switches that could be a 
good candidate for an abstract interface. I'm not sure what type 
of abstraction it should be, inherited SemaphoreImpl class, mixin 
member of a name given by OS module, fixed member name?

There is alot of confusion with the OS and clib as OS support 
functionality is mixed together with clib functionality in the 
code. This is very confusing. Instead if an abstract OS want to 
use clib, it should do so separately. For example Windows should 
use Microsoft Clib, Linux could use a variety of clib like glibc, 
musl etc. Clib support should be under OS support and not mixed 
into the generic code.

Another thing I've noticed is how elf code is duplicated for each 
OS. As elf is a standard we don't need to duplicate this and we 
can have a generic solution instead. We should have an ABI for 
this as well.

First I think we need to determine what type of "polymorphism" to 
use ie. how to select the OS specific implementation, then start 
to implement an ABI. Much of the ABI is straight forward I think.

BTW, isn't it time to retire make files and go for cmake only? 
Perhaps OT, I should start a new thread.