-
Notifications
You must be signed in to change notification settings - Fork 957
sbt 2.x (sbt in Scala 3) #6746
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
sbt 2.x (sbt in Scala 3) #6746
Conversation
b7c42e6 to
ac9e177
Compare
This comment was marked as outdated.
This comment was marked as outdated.
3f47daf to
ed2d460
Compare
2f4b042 to
f0c1976
Compare
820528e to
f498cb2
Compare
9e814b4 to
8181a33
Compare
2cdd136 to
25b835d
Compare
| @@ -20,6 +20,7 @@ import sbt.internal.util.Attributed | |||
| import Def.{ ScopedKey, Setting } | |||
| import Keys._ | |||
| import Configurations.{ Compile, Runtime } | |||
| import sbt.ProjectExtra.{ extract, runUnloadHooks, setProject } | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the changes to LoadBuildConfiguration, it looks like there may need to be an update to the def build method, or else global plugins fail to load, due to being passed the wrong BASE directory:
java.lang.RuntimeException: /Users/julianpeeters/.sbt/2.0.0-alpha6-SNAPSHOT/plugins/global.sbt cannot be mapped using the root paths
Map(
BASE -> /Users/julianpeeters/Workspace/hello-global,
SBT_BOOT -> /Users/julianpeeters/.sbt/boot,
IVY_HOME -> /Users/julianpeeters/.ivy2,
JAVA_HOME -> /Users/julianpeeters/.sdkman/candidates/java/17.0.1-oracle
)
def build(base: File, s: State, config: LoadBuildConfiguration): (BuildStructure, State) = {
val newConverter =
MappedFileConverter(config.converter.rootPaths2.toMap.updated("BASE", base.toPath), false)
val newInject =r
config.injectSettings.copy(global = config.injectSettings.global ++ globalPluginSettings)
val globalConfig = config.copy(
injectSettings = newInject,
pluginManagement = config.pluginManagement.forGlobalPlugin,
converter = newConverter
)See https://eed3si9n.com/simplifying-sbt-with-common-settings/ Problem ------- The behavior of bare settings is confusing in a multi-project build. This is partly due to the fact that to use `ThisBuild` scoping the build user needs to be aware of the task implementation, and know if the task is already defined at project level. Solution -------- This changes the interpretation of the baresettings to be common settings, which works similar to the way `ThisBuild` behaves in sbt 1.x, but since this would be a simple append at project-level, it should work for any tasks or settings.
Problem ------- In sbt 1, platform cross building is implemented using in the user-land using `%%%` operator, which clevery handles both Scala cross building and appending platform suffix like sjs1. However, in general symbolic `%%%` is confusing, and hard to explain. Solution -------- In sbt 2, we should subsume the idea of platform cross building, so `%%` can act as the current `%%%` operator. This adds a new setting called `platform`, which defaults to `Platform.jvm` by default. When a subprojects sets it to `Platform.sjs1`, `ModuleID`s defined using `%%` operator will inject the platform suffix `_sjs1` **in addition** to the Scala binary suffix `_2.13` etc. Note: Explicit JVM dependencies will now require `.platform(Platform.jvm)`.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest we remove those Scala 2 files if we don't need to cross-compile collectionProj anymore.
| // Construct these StringTypeTags manually, because they're used at the very startup of sbt | ||
| // and we'll try not to initialize the universe by using the StringTypeTag.apply that requires a TypeTag | ||
| // A better long-term solution could be to make StringTypeTag.apply a macro. | ||
| lazy val stringTypeTagThrowable = StringTypeTag[Throwable]("scala.Throwable") | ||
| lazy val stringTypeTagTraceEvent = StringTypeTag[TraceEvent]("sbt.internal.util.TraceEvent") | ||
| lazy val stringTypeTagSuccessEvent = StringTypeTag[SuccessEvent]("sbt.internal.util.SuccessEvent") | ||
| lazy val stringTypeTagThrowable = StringTypeTag.manually[Throwable]("java.lang.Throwable") | ||
| lazy val stringTypeTagTraceEvent = | ||
| StringTypeTag.manually[TraceEvent]("sbt.internal.util.TraceEvent") | ||
| lazy val stringTypeTagSuccessEvent = | ||
| StringTypeTag.manually[SuccessEvent]("sbt.internal.util.SuccessEvent") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since StringTypeTag.apply is a macro, we don't need to initialize those manually anymore.
| def ignoreResult[T](f: => T): Unit = macro Macro.ignore | ||
| def ignoreResult[A](f: => A): Unit = | ||
| f; () |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why was it a macro and it is not anymore? Should we inline it?
| @deprecated("Use LineReader apis", "1.4.0") | ||
| private[sbt] object JLine { | ||
| @deprecated("For binary compatibility only", "1.4.0") | ||
| protected[this] val originalIn = new FileInputStream(FileDescriptor.in) | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we remove JLine completely? It only contains deprecated methods.
| /** | ||
| * Arity-generic List. An abstraction over structured Tuple/List type constructor `X1[f[a]]`. | ||
| */ | ||
| trait AList[K[F[_]]]: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AList on tuples was much more simpler to understand.
We do need to treat AList like a typeclass after all because
sbt.std.Transform.uniform needs to traverse over a List,
and we won't be able to magically connvert a List into a tuple.
We can use Tuple.fromArray(list.toArray) instead, if it doesn't impact the performance too much.
|
|
||
| // bridge.runInParallel( | ||
| // sourcePath, | ||
| // bufferLog, | ||
| // args.toArray, | ||
| // launchOpts.toArray, | ||
| // callback, | ||
| // scalaVersion, | ||
| // sbtVersion, | ||
| // classpath.toArray, | ||
| // instances | ||
| // ) | ||
| bridge.runInParallel( | ||
| sourcePath, | ||
| bufferLog, | ||
| args.toArray, | ||
| launcherJar, | ||
| "java", | ||
| launchOpts.toArray, | ||
| callback, | ||
| scalaVersion, | ||
| sbtVersion, | ||
| classpath.toArray, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you remember the purpose of these changes?
| ThisBuild / scalafmtOnCompile := !(Global / insideCI).value | ||
| ThisBuild / Test / scalafmtOnCompile := !(Global / insideCI).value | ||
| ThisBuild / turbo := true | ||
| // ThisBuild / turbo := true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why disabling turbo mode? Does it make the tests flaky?
| pollInterval, | ||
| pushRemoteCacheArtifact, | ||
| sbt.nio.Keys.outputFileStamper, | ||
| sbt.nio.Keys.watchTriggers, | ||
| serverConnectionType, | ||
| serverIdleTimeout, | ||
| shellPrompt, | ||
| sLog, | ||
| traceLevel, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have a clue why we need to add more keys to excludeLintKeys?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you remember why you renamed project to project1?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LinterDS and TaskLinterDSL are not ported? What are they supposed to do? Should we try to port them or remove them?
We should probably drop Scala 2.x cross build.
In some situations maybe, but you may have noticed I am a big fan of the new syntax, so I think we should just use Scala 3 as intended with all the bells and whistles. |
Yea. Let's merge this as-is, and I'll come back to this PR to respond to comments and todos. |
This is a work-in-progress port to Scala 3, some of which documented as sudori: