{dmd, druntime} -> {dmd+druntime} i.e. Monorepo?

[max haughton]

On Tuesday, 24 August 2021 at 13:18:11 UTC, Steven Schveighoffer 
wrote:
> On 8/22/21 9:01 PM, max haughton wrote:
>> [...]
>
> druntime is comprised of several pieces:
>
> 1. Compiler support (GC, [associative] array runtime, TypeInfo, 
> etc.)
> 2. Runtime startup (running the module 
> constructors/destructors, handling exceptions not caught by 
> `main`, etc.)
> 3. Library code that is needed for items 1 and 2. For example, 
> core.time isn't really "runtime", but is needed by the runtime 
> for many parts.
>
> It's hard to split any of these out. I don't know that 
> core.time should be part of the compiler. Or core.thread. 
> Really, only the compiler-linked parts really belong in the 
> compiler repository. For instance the functions that implement 
> string switching. I listed the GC in that section because the 
> compiler has hooks into the GC, but I don't know if I'd count 
> the GC as part of the compiler.
>
> More stuff gets shoved into druntime because we don't want to 
> implement it twice (once in druntime, once in phobos), and as 
> the features of the compiler become more implementable in the 
> library, we can move things there to simplify and streamline 
> the compiler.
>
> I think a great project would be to do an analysis of all the 
> dependencies between the compiler and the runtime (and 
> phobos!), and then discuss how we would design it today if we 
> had the chance, knowing what we know now.
>
> As far as merging the two repositories, it's more of the same 
> shoving of stuff where it doesn't belong because something is 
> difficult (i.e. co-dependent PRs) or inconvenient. There's 
> alternatives as well, we could use some sort of tagging to 
> identify co-dependent PRs to make sure they are tested together.
>
> -Steve

The actual topology of the codebases would stay the same (or at 
least changes to it don't matter for the purposes of what I am 
suggesting), it's just the simplest way I can think of to 
streamline our current process. Semantically they are tied 
together very strongly and the same is true of our development 
process.

I also don't think our CI is particularly reliable and I think 
this would help.