Hi Andrius
Sorry 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).
FYI
sbt 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, mer...@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
