-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[PoC] Add multimodule support to Scala CLI ⚠️ #3085
base: main
Are you sure you want to change the base?
[PoC] Add multimodule support to Scala CLI ⚠️ #3085
Conversation
dc40778
to
ea0acc0
Compare
- copy HasGeneratedSources.scala into ManagesBuildTargets.scala - copy HasGeneratedSourcesImpl.scala into ManagesBuildTargetsImpl.scala.
Use ProjectName class instead of plain String
…inputs for further processing
… and complicates the build process in compose mode.
…ut in reality does not test anything with the last call to compile.
Without diving into the changes, how could this PR address scenarios like full-stack apps - e.g. where you need to bundle some compiled scala-js into a route from a scala jvm server |
…ependencies, WIP - test still needs fixing
ea0acc0
to
812bce1
Compare
@bishabosha I haven't given much thought to Scala JS, when preparing those changes and I'm not sure if building with Scala JS and depending on other modules will work out of the box with the changes prepared here. |
This PR is posted here to get some opinions on whether this is valid at all, not really in the code-sense but rather in the "Scala CLI as the official Scala runner"-sense.
This is a proof of concept PR stemming from previous work on scala-compose repo. The goal is to add support for projects containing multiple modules, each with separate classpath, that can depend on each other. Presented changes introduce BSP support that seems to work with Metals and a little worse with IntelliJ. This is still a work in progress and there are some things to figure out before this could be merged.
The main idea is to reuse the code that we already have for single module projects and simply loop over modules, calling functions same as before. This, in most parts avoids touching critical elements of the logic. Also, it allows for the behaviour to stay exactly the same when operating on single module projects.
The outline of the changes done to the code base:
HasGeneratedSources
toManagesBuildTargets
- the oldHasGeneratedSourcesImpl
assumed that the project contains only one module and operated on its Scopes keeping a map of those, new implementation keeps the same information by theProjectName
key which allows to store the Main and Test build targets same as before, but can handle mutliple of those. We're mostly relying on Bloop to keep the BSP standard while comunicating with the IDE client, so supporting mutliple build targets is ready out of the box if we can keep track of them. This change seems really safe - only one test blew up due to some race condition that I was not able to track down 😞.Inputs
class that aggregates information about files that get fed into the build process and also validates them. To multiply the instances ofInputs
(renamed toModuleInputs
and later toModules
) I introduced theInputsComposer
class that analyzes the configuration frommodules.toml
and creates instances ofInputs
with the correct links between them. Putting this code intobsp
andsetup-ide
commands is quite simple - it basically requires to switch to working onSeq[Inputs]
instead ofInputs
.run
command which resulted in introducing a new trait with the old nameInputs
that kept track of which module is the "target" of the command and allows to compute the compile order of modules (also keep some universal stuff like workspace path to not callSeq[Inputs].head.workspace
everywhere).Things that still need figuring out:
.scala-build/target-123/classes/main
which does not contain external sources like libraries, this will require some reorganization of the build procedure so that we stop after computing each build target'sProject
, link them together and the proceed with calling Bloop for compilation.