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: https://github.com/scalameta/metals/issues/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.

[lihaoyi]

Going to call this stale given the recent overhaul of BSP support. Feel free to re-open if it still happens on 1.0.0-RC2 or later

[lefou]

I'm not aware of any newly introduced logic that is solving this issue.

[arturaz]

@kasiaMarek can you elaborate on whether out/test/compiledClassesAndSemanticDbFiles.dest should contain classes from both main and test modules or there should be separate out/main/compiledClassesAndSemanticDbFiles.dest and out/test/compiledClassesAndSemanticDbFiles.dest with their respective files?

[lefou]

We should never mix the output paths of different modules. The issue at hand is only when a change happends after a BSP build. That is enough to see, that the current structure (which does not copy files from a main module into the test module outputs) is ok. All we need to fix is, that we properly trigger all transitive compiledClassesAndSemanticDbFiles task.

Currently, a build request for test re-triggers the main-compilation, but not the semanticDb files production.