Metals compile only one build target after source file is modified

[kpodsiad]

It is possible for a source file to belong to many build targets (e.g. multiple scala versions have the same sources)/ However, Metals store information about only one build target - see DependencySources. Both setBuildTarget and getBuildTarget methods operates only on a single build target. Because of that:

• it isn't possible to retrieve all build targets id for which file belongs BuildTargets.inverseSources
• after modifying a file, compilation for only one build target happens - see compile and expand file to build target

1. Is it possible to map the source file to the build target in another way using different mechanism?
2. Can triggerring compilation for all build targets be, for some reasons, problematic and unwanted?

[keynmol]

Can triggerring compilation for all build targets be, for some reasons, problematic and unwanted?

My one consideration is performance. It's not unrealistic to imagine that a single source file in a modern Scala library (sic!) will belong to a combination of:

1. Scala.js
2. Scala Native
3. JVM
4. 3 Scala versions (at least)

And if you edit the file and it triggers this matrix of 9 projects re-compiling, that can be problematic. (if they're recompiled in parallel)

On the other hand, if my edit breaks the file for even 1 target, I would like to know it (a common scenario was when I was adding Scala 3 to libraries and knowing what cross-compiles and what doesn't was very good).

With the nature of things how they are (multi-platform, multi-scala versions, and possibly more axes), I would love if matrix-like projects and their sources were normalised and weren't ignored by Metals.

[keynmol]

To add to this - if plurality of build targets were to be normalised, then Metals could use a mechanism to group/report individually diagnostics from different targets even if they fall on the same physical source location.

[tgodzik]

Could we for example do full compilation of all build targets on Cascade compile but otherwise only compile the most relevant one? This would be kind of a middle ground as Cascade compile is not invoked too often.

[Baccata]

but otherwise only compile the most relevant one?

A way for the end user to hint to metals what the most relevant one is would be great.