Hi Andrius,
Den 27.09.2019 10:15, skrev mer...@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?
