refactor: rework/rethink the meta meta build stuff

[ckipp01]

So I keep just thinking about this.... what if we got rid of all the meta-meta build nonsense. I'm just playing around with this for now, so don't freak out. However, there are a few things we do lose with doing something like this, but I think the benefit of not having an insane build is pretty high.

Here are a few things I'm looking into since I know this change would affect them:

1. We no longer dogfood. However, does that really matter? We're not really making changes to the sbt plugin often and I'd argue that i'd rather just have scripted tests or manual testing to ensure something then relying on the self published shaded naked self thingy that currently happens
2. The benchmark bridge would need some re-adjustments. Although it's not 100% clear why we can't just rely on a self published snapshot that gets created right before we run the benchmarks instead of relying on the sbt-bloop-build-naked.

Again, heavily a WIP, but just playing around with the idea of burning all the meta meta stuff down to the grown. It's so much easier to work with without all of it. I'm gonna just rip everything out, start testing, and see what breaks and then try to address them.

[tgodzik]

Btw. I am all for it, thanks Chris for delving into these depths of madness and despair.

[bloopoid]

Performance test finished successfully.

Benchmarks is based on merging with master

[ckipp01]

Alright, so I'm pretty confident with this at the moment, and quite happy with it. Much of it was mimicking what @alexarchambault did in bloop-core by just ripping it all out.

As I stated in the initial description, it seems that the entire notion of having the sbt-bloop-build-naked and the bloop-shaded-plugin is primarily to dogfood itself in a way that doesn't conflict with the issue that is outlined in sbt/sbt#892. Maybe at one point in time when we were rapidly developing the sbt plugin and build and always wanting to dogfood those changes this may have been worth it, but I don't think it is anymore. The entire meta-meta build can just be thrown away if we get rid of the idea of wanting to do this. Instead, we just ensure that we publish sbt-bloop before situations where we want to ensure we're using that. This is primarily when we're running the frontent tests and we an the Bloop definitions of the projects in the frontent resources and when we're running buildpress. In both of these scenarios we just publish sbt-bloop first, and it works the same way. Benchmarks will also work exactly the same as the version is passed directly to it that we're using. We included the sbt-bloop-build-naked there before, but from my understanding it was again only to dogfood the bloop generation when we can just use the one we just published.

So to outline the changes, this

• gets rid of the sbt-bloop-build-naked
• gets rid of the bloop-build-shaded-plugin
• benchpress is still able to run fine
• frontend test resources are still able to be generated fine
• tests all still pass
• the build is way less crazy

The main thing we lose out on is:

• We no longer dogfood the absolute latest changes

This is a tradeoff I'm 100% ok with. If the others are as well I can merge in scalacenter/compiler-benchmark#9 (this pr is pointing to my own fork at the moment), and then I'll update this pr to use it.

[adpi2]

✔️ 💯 ✔️

[tgodzik]

This is beautiful! 😍

[oyvindberg]

What a fantastic improvement! I wanted this since the first time I saw the build :)