Generate only one build target for main and test scope

[lwronski]

No description provided.

[romanowski]

Should we ignore errors from post process?

Also a small nit, you can combine collect and map into one call

[alexarchambault]

I'm still unsure what these changes do precisely, but if the CI is green, I guess it's fine.

[lwronski]

I'm still unsure what these changes do precisely, but if the CI is green, I guess it's fine.

1. I want to generate a build hash based only on the main scope. Previously, in test scope hash was different, because scala-cli added mainClassPath to testBuildOptions. Therefore, I move building scopes to one method and count hash only once.

2. Moving postProcess method to build method - after building main scope, postProcess method move semanticdb files from:
   $project-name/META-INF/semanticdb/.scala-build/project_4955484392-7cfa0b230b/src_generated/main/simple.scala.semanticdb,
   to $project-name/META-INF/semanticdb/simple.sc.semanticdb. And then, we run building test scope which is dependent from main scope, and in this cases, Bloop see that main target was changed, so it compile again. Therefore, I moved running post process method into build method.

[alexarchambault]

1. I want to generate a build hash based only on the main scope. Previously, in test scope hash was different, because scala-cli added mainClassPath to testBuildOptions. Therefore, I move building scopes to one method and count hash only once.

This works only if no test-specific options are enabled, right? (like //> using options "-Xasync" added in a *.test.scala file) If not, that means if users change test-specific options manually, an already on-going build and a new one picking the new options might clash (because they'd use the same project directory, only based on the options from the main scope).

[alexarchambault]

Ok, I saw the test options taken into account when computing the project hash… :)