[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Status of sbt package



Hi Andrius,

Den 27.09.2019 10:15, skrev merkys@debian.org:
I have managed to get around Scala FTBFS problem [1] for now, will
continue looking into your script.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941211

Are you trying to compile scala 2.11.12 from the source debian package or from the scalateams 2.11.12 src tar ball? Are you doing that to use it as the base to compile 2.12.0-M1, to be able to compile sbt or just to get expereience with build script build-2.12.0-M1.sh?

The bug report mentioned maven? I am nort familiar with the build procedure described, are you using maven to start the ant build script? Or have I got it all wrong?

jline v2.14.6 is in Debian as libjline2-java, wouldn't this work?

I experimented with using the jline from /usr/share/scala/lib, but it did not work, I think the problem is not jline in it self, but rather that the bootclasspath is different in the debian package than the local installation of scala 2.11.12 I used when writing the initial script.

By the
way, how are the jars under $BUILDMODULEPATH built?

The short answer is its the release library jars that comes with the scala release of 2.11.12, so its precompiled. Also some of the jars I just copied from the release tarball to be able to test if it I can compile a test scala class and run it. Specifically jline, scala-xml, config and a few others.

The long answer is, in two parts  (I appologise if this is obvious...)
1- I downloaded from efpl the release of 2.11.12 and used that as the compiler for the build. So when setting up the booclasspath I had to control which jars were included at the different stages of the compilation script. The next answer explains why. 2- Since we are compiling a compiler, we need to incrementally exchange the old version of the scala jar files with the newly compiled version, otherwise the new scala version wont run (abstract method error). This means overriding the complete bootclasspath for the jvm, not just scala booclasspath.

So the strategy is simple, but technically confusing at times, by manually creating a new and complete javabootclasspath:
- get all jars from the jre, they are put last on the bootCP
- get all jars from the scala libs, they are put second to last on the bootCP - first use all this to build the first module of the new scala version: scala-library - replace old scala-library jar (from 2.11.12) with newly compiled library-jar (2.12.0-M1) on the bootCP (put first on bootCP to guarantee shadowing of the old version) - as the modules are built, keep replacing the old with the new, in the order of asm, forkjoin, library, reflect, compiler, scalap, repl, interactive

The jars the script produces ar not package exactly the same as the efpl release jars are, so that might be a bit configusing


Btw, maybe we should start a new thread about the scala compilation stuff so its easier for all to see what the discussions are actually about?


Reply to: