Hi AndriusSorry for the delay in answering, I'm on daddy-leave so time is scarce. (and sorry for the long mail... :) )
I have some more good news :) After battling with my own and other demons I have managed to create a shell script for compiling Scala 2.12.0-M1. The experiences from that can probably be used to create a similar script for Sbt.
The original build file (sbt) for Scala is miles long and has lots of stuff not needed for creating a debian package. I suspect the same is true for Sbt. The original scripts have all sorts of bootstrapping, infrastructure, test and other administrative or maintenance parts, which is not needed for our purpose. All that is taken care of upstream, we just need to build and ship it.
My strategy was reverse engineering of the build process, using the scala version that exists in Debian (2.11.12) and verbose mode in sbt to study the output from a compilation or packaging task. I know a different strategy was used for Sbt, but I think this is the more viable solution.
A Scala release build is somewhat different from a Sbt release build. Since I was compiling the compiler, I needed to override the bootclasspath so that the new project modules replaced the older modules on the bootclasspath. Thats not a problem for sbt, but there still might be some interresting classpath issues when compiling sbt.
You can have a look at what I have done at https://bitbucket.org/tfinneid/scala-build-process/src/default/build-2.12.0-M1.sh(The scripts is a very naive version, but it actually caused me more headache trying to creating a more automatic version of the script while, at the same time, trying to figure out the correct Scala build process and command arguments to get a working scala release)
I think one of the bigger issues for creating a working sbt debian package is: - sbt downloads the projects correct sbt version and other dependencies and compiles the compiler interface for the correct scala version before making the project available on sbt command line - Setting that up correctly for the installed package, might not be as easy as one thinks. - I experienced some problems with that when testing the existing sbt package in debian on a minor test project I created. - I found that project dependencies was only retrieved from local files installed by the package, not from the network as it should (this applies to the completed and installed binary package, not the building of the package - other than that sbt external build dependencies must either exist as jar files in debian or be created as separate packages (or included as a separate pre-compile step in the sbt build script.
Also, check what version of the jvm Sbt was originally built with. Scala 2.12 is built using Java 8 and hence only properly compatible with that. Scala 2.12.10 (at least) and 2.13 supports jdk11, but its still built with jdk8 (not target argument, but actual jdk8 release).
FYIsbt 0.13 is required for Scala 2.12, while sbt 1.0 is required for Scala 2.13 builds. I dont know if that is important information yet, it depends on the strategy for moving forward.
Hope this helps. And I love to hear what you find and share my experiences. Thomas On 10.09.2019 17:56, merkys@debian.org wrote:
Hi Frédéric and Thomas, Sorry for the delay. I must admit I wasn't aware the dogfooding problem is so difficult to avoid. On 2019-08-17 07:53, Thomas Finneid wrote:The good news is that after talking with some of the maintainers of Sbt and Scala, they would be very interrested in getting a script that could build Sbt or Scala from command line, using just Java and similr tools.This solution sounds the best. Do you know whether the upstream would be willing to help with writing and maintaining such a script? Building sbt from 0.13.13 incrementally would be an option too, should the previous one fail. However, to build sbt incrementally one would probably need to demote its dependencies to make them compatible with this ancient version of source. Not sure where to start, though. Thanks for sharing your experience. Best, Andrius