druntime redesign

[Denis Feklushkin]

On Sunday, 15 March 2020 at 12:08:54 UTC, IGotD- wrote:
> On Sunday, 15 March 2020 at 10:29:11 UTC, Denis Feklushkin
>> 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?

It’s definitely not a class because in this case it is not 
required to provide polymorphism - there is only one platform 
will be presented in result binary. (If someone occasionally 
wants to make a multi-platform binaries it will still be more 
difficult than just several implementations of these base class.)

Just fixed member is preferred, as for me.

>
> 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.

My investigation showed me that there is not so much of this libc 
code. I even think that it will be possible to introduce  
temporary abstract libc version(CRuntime_AbstractLibc) to cover 
this case.

>
> 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.

And, probably, not all platforms need ELF support in druntime.

> 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.

Just improve makefiles to be able select needed subdirectories 
like in
posix.mak/win64.mak and LDC's druntime CMakeLists.txt:

# only include core/sys/ modules matching the platform
file(GLOB_RECURSE DRUNTIME_D_BIONIC  
${RUNTIME_DIR}/src/core/sys/bionic/*.d)
file(GLOB_RECURSE DRUNTIME_D_DARWIN  
${RUNTIME_DIR}/src/core/sys/darwin/*.d)
file(GLOB_RECURSE DRUNTIME_D_DRAGONFLYBSD 
${RUNTIME_DIR}/src/core/sys/dragonflybsd/*.d)
file(GLOB_RECURSE DRUNTIME_D_FREEBSD 
${RUNTIME_DIR}/src/core/sys/freebsd/*.d)
file(GLOB_RECURSE DRUNTIME_D_LINUX   
${RUNTIME_DIR}/src/core/sys/linux/*.d)
file(GLOB_RECURSE DRUNTIME_D_NETBSD  
${RUNTIME_DIR}/src/core/sys/netbsd/*.d)
file(GLOB_RECURSE DRUNTIME_D_OPENBSD 
${RUNTIME_DIR}/src/core/sys/openbsd/*.d)
file(GLOB_RECURSE DRUNTIME_D_POSIX   
${RUNTIME_DIR}/src/core/sys/posix/*.d)
file(GLOB_RECURSE DRUNTIME_D_SOLARIS 
${RUNTIME_DIR}/src/core/sys/solaris/*.d)
file(GLOB_RECURSE DRUNTIME_D_WINDOWS 
${RUNTIME_DIR}/src/core/sys/windows/*.d)

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

Do you know a mind state when you recognize a new tool and it 
starts to seem perfect and you want to use it everywhere and 
always? So for me now this tool is Meson build system. Therefore, 
I am biased.

Maybe we should consider switching to it. It is ideal for D in 
terms of the ability to simplified link programs written in 
various languages.

In fact, I'm not going to use druntime with existing built-in 
make/cmake scripts in my Dlang MCU projects because it are too 
complex and it is very difficult to configure to support dozens 
of all kinds of options that microcontroller binaries need.