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

Steven Schveighoffer schveiguy at gmail.com
Tue Aug 24 13:18:11 UTC 2021


On 8/22/21 9:01 PM, max haughton wrote:
> Thesis: Develop dmd and druntime together in a monorepo, since they are 
> developed and shipped together. I think this could potentially save a 
> lot of hassle for both developers and consumers, especially the former: 
> No more waiting for druntime PRs to go through, and hopefully less 
> CI-senbugs.
> 
> Antithesis?

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


More information about the Digitalmars-d mailing list