Skip to content
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.

Sign up for GitHub

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

Make SbtBuildTool respect crossScalaVersions #5637

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

Make SbtBuildTool respect crossScalaVersions #5637

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion metals/src/main/scala/scala/meta/internal/builds/SbtBuildTool.scala
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -44,7 +44,7 @@ case class SbtBuildTool(
override def bloopInstallArgs(workspace: AbsolutePath): List[String] = {
val bloopInstallArgs = List[String](
"-Dbloop.export-jar-classifiers=sources",
"bloopInstall",
"+bloopInstall",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One problem would be that configuration would be overridden. We need to have scala version added to the name of the bloop json file.

I wouldn't make it as a default also, in some projects this might produce a large number of targets, so ideally this would be opt in.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One problem would be that configuration would be overridden. We need to have scala version added to the name of the bloop json file.

Can you point me to where the logic is for picking up the various bloop.json files?

I wouldn't make it as a default also, in some projects this might produce a large number of targets, so ideally this would be opt in.

Sure, I would say first lets get the feature working. I think it might be possible to do improvements in this regard, i.e. it seems that various scala 2 versions can share the same build target and its only with scala 3 where its problematic, in which case I don't think the "explosion" in build targets is that big and maybe can be justified as default behaviour.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for not getting back sooner, I was off on vacation and just got back to the issue.

We could potentially change the name to include scala version here:

https://github.com/scalacenter/bloop/blob/main/integrations/sbt-bloop/src/main/scala/bloop/integrations/sbt/SbtBloop.scala#L912

either by adding another setting, which we would set while running +bloopInstall or maybe its possible to detect that case (if we are running with a +)

We can't really just change the name general unless we make sure that the old filenames are replaced.

Are you still interested in pursuing this?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for not getting back sooner, I was off on vacation and just got back to the issue.

Likewise, sorry for not getting back to the comment I was at a wedding.

We could potentially change the name to include scala version here:

https://github.com/scalacenter/bloop/blob/main/integrations/sbt-bloop/src/main/scala/bloop/integrations/sbt/SbtBloop.scala#L912

either by adding another setting, which we would set while running +bloopInstall or maybe its possible to detect that case (if we are running with a +)

We can't really just change the name general unless we make sure that the old filenames are replaced.

Thanks I will look into this

Are you still interested in pursuing this?

I am but I have a lot on my plate right now so I will probably get to it close to the end of the year, feel free to pick it up sooner if it makes sense to do so. One thing that I had in my mind is creating a new sbt command in sbt-bloop along the lines of bloopInstallAllRelevantVersions (feel free to bikeshed name) which will generate the bloop json for only the necessary Scala versions rather than just blindly for all Scala versions in crossScalaVersions. This is based on the presumption (which I have noticed, correct me if I am wrong) that at least for Scala 2, bloop/metals seems to work with all Scala 2 with just a single generated bloop json for Scala 2 so the idea behind the bloopInstallAllRelevantVersions command is that it will find the "best" Scala 2 version and generate the bloop json from that and then if you happen to also have Scala 3 it will generate a bloop json of that.

The idea is that this is a compromise between not generating bloop json for all scala versions and only for the Scala version set in scalaVersion, i.e. we would have at most 2 generated bloop.json (if you have a cross Scala 2/Scala 3 project although I am not factoring in Scala.js/scala-native, not sure how this works).

Let me know what you think.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we could make it a bit smarter I think, though that might be complex. We could potentially generate json files for anything that has custom sources. So if it differs from the default, we would generate an additional json file. This way if a project only cross compiles the same sources we would have a single json file.

Though I imagine not everyone would want to have all targets always since it makes the full compilation take much longer. This doesn't also solve the issue for sbt BSP (though I imagine it should be able to control it from the command line even if it's not possible now).

Maybe we should three import modes:

  • simple import the same as currently
  • import all possible targets
  • import all that contain non standard sources (optionally)

Alternatively instead of the last mode, we could allow turning off some modules in the doctor, which would be saved between the sessions. Or we could allow to import a different Scala Version with a manual input (as a workaround of the current default mode).

)
val allArgs = composeArgs(bloopInstallArgs, workspace, tempDir)
removeLegacyGlobalPlugin()
Expand Down
Loading