Fixes #2196, Specify the compiler bridge module in a setting#2197
Fixes #2196, Specify the compiler bridge module in a setting#2197
Conversation
In order to restore reproducibility of builds, we no longer cascade over the possibly available versions of the compiler bridge sources (a specific version of the bridge sources may not be available one day, but exist on the next day), but rather let the build definition configure which module to use. Fixes sbt#2196
Note that they won't be downloaded again, because the component compiler will look for a previously-compiled version of the compiler bridge before trying to fetch the sources again. If they've already been downlaoded, then they have been compiled and a compiled version of the compiler bridge already exists.
|
Can one of the admins verify this patch? |
This will avoid all clashes between modules that may have the same name as other components of sbt, or two different compiler bridges that would happen to have the same name.
|
From as much as I understand what's going on, this LGTM. |
|
LGTM |
There was a problem hiding this comment.
Think this should be a sequence, so I could have it be the "hierarchy" if I wanted.
There was a problem hiding this comment.
That's what the original design document said too, but I think Seq[ModuleID] means you still are reliant on the state of Internet, which defies the purpose of this change.
There was a problem hiding this comment.
Actually the idea is to replace the hierarchy by specifying directly in the build definition what version of the compiler bridge is required. After the compiler bridges have been split, it will become something like:
scalaCompilerBirdgeSource := scalaVersion.value match {
case v if v startsWith "2.11" => "org.scala-sbt" % "compiler-interface" % sbtVersion.value
case _ => "org.scala-sbt" % "compiler-interface-old" % sbtVersion.value
}This way we keep the flexibility, but we don't rely on the hypothetical existence of some artefacts. The same build could yield totally different result depending on the availability of a specific compiler interface source at some point.
There was a problem hiding this comment.
The issue is about forward compatibility here. If Scala 2.12 comes out and requires specific sources, then sbt 0.13.x will not work anymore until a new release comes out.
I understand the reasoning, I just wanted to err on the side of forward compatibility and letting the Scala team release their own bridge-sources if needed for milestone releases. You guys do not remember the pain-days of pre-scala-bridge-stability.
Fixes #2196, Specify the compiler bridge module in a setting
|
Ref #681 |
Fixes #2196
In order to restore reproducibility of builds, we no longer cascade over
the possibly available versions of the compiler bridge sources (a
specific version of the bridge sources may not be available one day, but
exist on the next day), but rather let the build definition configure
which module to use.
Also, download the compiler bridge sources and its dependencies in a temporary directory. We don't need to keep them around, because the next time we try to compile using this specific version of the compiler bridge, we will be able to immediately find the compiled version.