Support multiple separate build targets #3126
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Nit:Remove maybeUpdateProjectTargetUri as ProjectName always has targetUriOpt set Nit: Add named arguments to a buildOnce call
- copy HasGeneratedSources.scala into ManagesBuildTargets.scala - copy HasGeneratedSourcesImpl.scala into ManagesBuildTargetsImpl.scala.
Use ProjectName class instead of plain String
…inputs for further processing Implement a new trait Inputs, that aggregates ModuleInputs Use InputsComposer in Bsp and SetupIde Add method for picking the highest version of JVM from BuildOptions
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Had some time to fix a big problem in the way of #3085 - #3112.
After that is gone, moving from the PoC to its basic, still exciting version was very tempting. And so here we are.
This PR introduces support for multiple build targets in the BSP mode. Build targets are not in any way related, their classpath and project configuration should be totally separate, except of course for options passed from CLI which will be applied to all.
Setting up of build targets can be done with a
.tomlfile where we define all build targets together with their roots - which corresponds to how all Scala CLI projects start their preprocessing - args from CLI. The rest is just for looping over the build targets doing the same stuff we always do.The toml looks like this:
Where no roots is defined the name is picked and so the root of module
corewill becore/in the project workspace.