Consider migrating back to sbt/zinc #1383
Comments
|
We are starting to work on this, based on @Duhemm feedback we plan to do the migration in two main step steps.
@jvican let me know if there is something that is totally off with this plan. I know that removing pipelining means a lot of the previous work goes to waste, but having two implementations of pipelining is not maintainable for us in the long run. |
|
@tgodzik do we have any sense yet, even a vague one, of when 1.5.0 might happen? |
|
(My specific motivation for asking it that since scala-cli is built on bloop, perhaps this ticket should be considered a blocker for scala-cli becoming the official Scala launcher. It seems like pretty bad news to me to have multiple independent implementations of incremental compilation floating around.) |
I started looking into that more now, so hopefully sooner than later. Sorry for taking that long, it's a bit of unknown waters for me 😓 |
In order to make upgrading versions easier we decided to switch back to sbt/zinc instead of a custom fork. The original reason for using the fork was to enable build pipelining, but that itself has been implemented in the orginal fork. Unfortunately, to make the migration easier we needed to remove build pipelining for now to later add it with the default mechanism. Related to scalacenter#1383 The benchmarks are being run to make sure we are not regressing in performance.
In order to make upgrading versions easier we decided to switch back to sbt/zinc instead of a custom fork. The original reason for using the fork was to enable build pipelining, but that itself has been implemented in the orginal fork. Unfortunately, to make the migration easier we needed to remove build pipelining for now to later add it with the default mechanism. Related to scalacenter#1383 The benchmarks are being run to make sure we are not regressing in performance.
In order to make upgrading versions easier we decided to switch back to sbt/zinc instead of a custom fork. The original reason for using the fork was to enable build pipelining, but that itself has been implemented in the orginal fork. Unfortunately, to make the migration easier we needed to remove build pipelining for now to later add it with the default mechanism. Related to scalacenter#1383 The benchmarks are being run to make sure we are not regressing in performance.
In order to make upgrading versions easier we decided to switch back to sbt/zinc instead of a custom fork. The original reason for using the fork was to enable build pipelining, but that itself has been implemented in the orginal fork. Unfortunately, to make the migration easier we needed to remove build pipelining for now to later add it with the default mechanism. Related to scalacenter#1383 The benchmarks are being run to make sure we are not regressing in performance.
|
@tgodzik I think we can close this one? Congrats and thank you 😄 |
|
Sure! I added a new issue about pipelining. |
Currently, Bloop is using a fork of Zinc (https://github.com/scalacenter/zinc) which is a bit outdated compared to sbt/zinc (https://github.com/sbt/zinc).
At the time, this fork was introduced to support features that weren't available in sbt/zinc, such as build pipelining for instance. In the meantime, sbt/zinc got support for build pipelining and received bug fixes and performance improvements. Porting these changes to our fork of Zinc would require a considerable effort.
Similarly, migrating to mainline Zinc is no small task and will most likely require a lot of changes to Bloop.
I don't think that Bloop benefits from using a fork of Zinc anymore. I'd be in favor of migrating Bloop back to sbt/zinc to get the recent improvements and avoid the cost of maintaining a fork of Zinc.
The text was updated successfully, but these errors were encountered: