Add abstraction over non-bootstrapped/bootstrapped/optimised builds

[nicolasstucki]

No description provided.

[smarter]

This is getting out of hand, we shouldn't be duplicating so much stuff in our build. We can make functions that return projects and use that to abstract over non-bootstrapped/bootstrapped/optimized, a bit like sbt-crossproject has functions to make jvm and js projects out of one thing.

[nicolasstucki]

I started working on factoring out project components and abstracting over non-bootstrapped/bootstrapped/optimized.

[smarter]

@sjrd could you have a look and tell us if you think this is a sane way to do things or if there's a better way?

[sjrd]

It looks decent as far as the bootstrapped/non-bootstrapped distinction goes. I am less convinced by the optimized distinction.

The reason is that you need the bootstrapped and non-bootstrapped projects to cohabit, since the former actually depends on the latter. The optimized versions, however, are just a variant of the bootstrapped thing, IIUC. That is better handled with a dynamic set, as was done before.

In general, things that can be done with a set should be. Reserve the multiple projects for things where the multiple projects actually to all live in a same run (typically because of dependencies). Otherwise your setup will not scale to other kinds of "configuration" tests. An example: you might want to test with and without applying -Xexperimental to the entire codebase (to take a scalac option I know; in dotty other things might apply).

[nicolasstucki]

After discussing with @sjrd, we concluded that having the set would not be the best setup for the current use case. Hence the current definition with all three versions of the projects in the one that we need for now. In the future, we might migrate to the other version.

@smarter @allanrenucci WDYT?

[smarter]

Could you describe that usecase?

[nicolasstucki]

I have two development use cases:

• Running benchmarks locally: Having two distinct projects and is needed as I do not want to clean and recompile twice the whole compiler twice each time I do a change.
• Comparing the dist jars: Again, if I do not have two separate projects I would need to clean and recompile twice each time I test some change. Additionally I would need to make copies of one set of artifacts before compiling the other, which makes the methodology quite brittle as already experienced.

[smarter]

I wonder if we could do something a bit more like sbt-crossproject, e.g:

lazy val compiler = dottyProject(NonBootstrapped, Bootstrapped, BootstrappedOptimized)
  .settings(dottyCompilerSettings)
  .bootstrappedSettings(bootstrappedCompilerSettings)
  ...
lazy val `dotty-compiler` = compiler.nonBootstrapped
lazy val `dotty-compiler-bootstrapped` = compiler.bootstrapped
lazy val `dotty-compiler-bootstrapped-optimized` = compiler.boostrappedOptimized

[nicolasstucki]

I will look to the crossproject idea later.