Classes don't seem to be always put in compiledClassesAndSemanticDbFiles.dest

[kasiaMarek]

Mill build server points to .../compiledClassesAndSemanticDbFiles.dest as the Classes Directory, but classes seem to be only put there when mill is explicitly asked to compile a specific build target.

Expectation

Mill should also put classes in compiledClassesAndSemanticDbFiles.dest for a build target that is compiled as a dependency.

Example

1. Have two build targets main and test, where test depends on main.
2. Compile test.
3. I'd expect to have classes in appropriate .../compiledClassesAndSemanticDbFiles.dest for both build targets.

More context

In Metals we use compiledClassesAndSemanticDbFiles.dest as part of the classpath for when debugging. Right now the user needs to first open all dependency modules, so classes will appear in the correct destination.
connected to: scalameta/metals#6579

[lefou]

Could this be some unsharpness in the BSP protocol spec? Metals wants to use some location to access JVM byte-code of a specific module and it's dependencies, but never requests the JVM byte-code to be produced for the dependencies.

This is also a limitation of the BSP protocol. Although, sementicDB files are not needed to debug something, BSP only supports a single output location for target files of a JVM bytecode files and a semanticDB files producer. So, Mill needs to provide the already produced JVM-byte-code in a shared location with the semanticDB files, which is only available after you have requested and produced both.

We could and probably should fix this on Mill's side by letting the copiledClassesAndSemanticbFiles target depend on its companions of its recursive dependencies. But it would be nice to also open an issue for BSP to get that detailed expectation into the written BSP spec.