Projects as sets of targets with shared configuration

[agluszak]

I propose that we add a notion of a project to the protocol. A project would be a set of build targets that share config/context.

What currently is an sbt target would become a BSP project. Its configuration would be scala version and environment (JVM/JS/native).
A cargo package would be a BSP project and its config would be the set of enabled features.
In Bazel there are no projects, as all targets have to be fully configured individually.
In Gradle there are projects (that would map 1-1 to BSP projects) and each projects contains tasks (what would become BSP targets).

[adpi2]

I would rather keep the build target as the biggest notion and add a sub notion of run target: a build contains many buildTargets and each buildTarget contains many runTargets.

[agluszak]

I would rather keep the build target as the biggest notion and add a sub notion of run target: a build contains many buildTargets and each buildTarget contains many runTargets.

But is it just a naming issue?

[adpi2]

But is it just a naming issue?

Yes and it is also a question of consistency. If we have a notion of buildTarget in BSP 2 and BSP 3 they should mean the same thing.

If we add the notion of project then all that is a buildTarget in the current implementations of sbt, Mill, Bloop, Metals and the IntelliJ Scala Plugin would become project, and buildTarget would appear somewhere else in the implementation. It would make the migration harder and confuse people.

[abrams27]

what do u mean by config/context? potentially in sbt / gradle JVM/JS targets can have different sources, does it mean that the "big" target / project will contain all the sources, or it's not the part of the config/context?