Community build progress report (August 2019)

[liufengyun]

@smarter

another possibility, not mutually exclusive with continuing with dbuild, is to spin up something like the community build that just compiles each project independently, without doing the dependency-rewiring thing. this would catch most classes of bugs

This is what dotty/community-build/test/scala/dotty/communitybuild at main · lampepfl/dotty · GitHub already does, but it’s going to stop working as soon as dotty projects start depending on other dotty projects given that we still regularly break the ABI.

If I were correct, breaking of ABI or type-binary-interface(TBI, e.g. Tasty) by compilers is not a regularity in Scala compiler development.

1. It only happens relatively often in a pre-production stage of a compiler, or
2. It may happen between big version changes of a production compiler ^[1].

Let’s call the first bootstrap problem, and the second migration problem.

It seems that the bootstrap problem is just temporary. Maybe a temporary solution is good enough for a temporary problem.

The migration problem is rare if it does occur. Maybe here we can isolate the problem from the problem of community build, and propose a temporary solution too?

Given the complexity of community build, I’d say we should optimize for reducing maintenance efforts. If it saves efforts on 90% of days and over 70% of the matrix, it’s already a win.

As a side effect, it will give us scalability — that is the possibility to add more projects and test more behaviors of compilers, that aligns with the primary goal of community build.

---

1. But Dotty artifacts are bin-compat with Scala2, and Dotty can compile with Scala2 libs (except for macros). I assume it’s more or less the case for major Scala2 compiler versions. ↩︎