Summary: | dev-lang/scala-2.10.2 version bump | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Joel <joel486> |
Component: | [OLD] Java | Assignee: | Mark Wright <gienah> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | keshav.kini, kevin.bowling, nathan0n5ire |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://www.scala-lang.org/node/27499 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 468344 | ||
Attachments: |
do not run git log commands during the build
an ebuild for discussion do not run git log commands during the build scala 2.10.2 ebuild - has QA issues needs a symlink: dosym "/usr/share/${JAVA_PKG_NAME}/lib" "/usr/share/${PN}/lib" proposed dev-lang/scala-2.10.2.ebuild scala jline fails to compile with 2.10.2 proposed dev-lang/scala-2.10.2.ebuild Thanks to Coy Barnes, add suggested fix jdk 1.7 swing patch jdk 1.7 swing |
Description
Joel
2013-01-04 20:37:44 UTC
JDK doesn't need to be hard coded to 1.6 either AFAICT. This appears to use Maven to download libraries, more effort is required here to get this fixed; USE=binary working alone is not sufficient, Java packages need to be compiled from source before they are added to the tree. We also can't just list their binary in SRC_URI, we need to actually reproduce it and host it ourselves. Scala 2.10.2 was just released. The source file no longer seems to be hosted at scala-lang.org, but I think I found it at https://github.com/scala/scala/archive/v2.10.2.tar.gz. Created attachment 356068 [details, diff]
do not run git log commands during the build
Created attachment 356070 [details]
an ebuild for discussion
(1) One test fails with OpenJDK 64-Bit Server VM 1.6.0_27
[partest] testing: [...]/files/run/parserJavaIdent.scala [FAILED]
[partest] java.nio.charset.MalformedInputException: Input length = 1
(2) 24 jar files are listed in SRC_URI
(3) It seems strange that I rename the 24 jar files to .jarx to avoid them being unpacked in src_unpack, I am not sure if there is a more elegant way to accomplish this.
(4) The java herd devs may be able to see other issues.
Created attachment 356160 [details, diff]
do not run git log commands during the build
I need to specify a real git hash in order for the src code hyperlinks to github to work in the scala API documentation.
Created attachment 356162 [details]
scala 2.10.2 ebuild - has QA issues
Updated the proposed ebuild for the comments, thanks, on #gentoo-java
The following QA issues are reported when emerging it:
* Class files not found via DEPEND in package.env
* org/apache/tools/ant/util/IdentityMapper.class
* org/fusesource/hawtjni/runtime/JniArg.class
* org/apache/tools/ant/types/Commandline$Argument.class
* org/apache/tools/ant/util/SourceFileScanner.class
* org/apache/tools/ant/types/Reference.class
* org/apache/tools/ant/types/FileSet.class
* org/apache/tools/ant/util/FileNameMapper.class
* scala/tools/partest/nest/RunnerManager$Runner$$anonfun$reportResult$1.class
* scala/tools/nsc/backend/jvm/GenJVM$BytecodeGenerator$$anonfun$computeLocalVarsIndex$1.class
* org/apache/tools/ant/BuildException.class
* scala/tools/nsc/interpreter/ByteCode$$anonfun$scalaSigBytesForPath$1.class
* org/apache/tools/ant/taskdefs/Java.class
* org/apache/tools/ant/types/Path.class
* scala/tools/nsc/backend/msil/GenMSIL$BytecodeGenerator$$anonfun$computeLocalVarsIndex$2.class
* scala/tools/nsc/backend/jvm/GenJVM$BytecodeGenerator$$anonfun$addInnerClasses$4.class
* org/apache/tools/ant/DirectoryScanner.class
* scala/tools/nsc/doc/model/MemberLookup$$anonfun$findExternalLink$2.class
* org/apache/tools/ant/types/Mapper.class
* scala/util/parsing/combinator/PackratParsers$$anonfun$scala$util$parsing$combinator$PackratParsers$$setupLR$2.class
* org/apache/tools/ant/taskdefs/MatchingTask.class
* org/apache/tools/ant/AntClassLoader.class
* scala/tools/nsc/doc/Settings$hardcoded$$anonfun$valueClassFilter$1.class
* org/apache/tools/ant/types/CommandlineJava.class
* scala/tools/nsc/backend/jvm/GenASM$JPlainBuilder$$anonfun$computeLocalVarsIndex$1.class
* org/apache/tools/ant/Project.class
* org/apache/tools/ant/util/FileUtils.class
* scala/tools/nsc/typechecker/SuperAccessors$SuperAccTransformer$$anonfun$3.class
* org/fusesource/hawtjni/runtime/JniClass.class
* org/apache/tools/ant/Task.class
* scala/tools/nsc/typechecker/Namers$Namer$$anonfun$templateSig$3.class
* org/apache/tools/ant/util/facade/FacadeTaskHelper.class
* scala/tools/nsc/interpreter/ByteCode$$anonfun$caseParamNamesForPath$1.class
* scala/tools/nsc/symtab/classfile/ClassfileParser$innerClasses$$anonfun$add$1.class
* scala/tools/nsc/symtab/classfile/ClassfileParser$$anonfun$loadClassSymbol$1.class
* scala/tools/nsc/backend/msil/GenMSIL$BytecodeGenerator$$anonfun$computeLocalVarsIndex$1.class
* scala/tools/nsc/typechecker/Namers$Namer$$anonfun$typesFromOverridden$1$1.class
* org/apache/tools/ant/util/facade/ImplementationSpecificArgument.class
* org/apache/tools/ant/util/GlobPatternMapper.class
Created attachment 356168 [details]
needs a symlink: dosym "/usr/share/${JAVA_PKG_NAME}/lib" "/usr/share/${PN}/lib"
Still has the QA issues reported earlier. Needs testing, I am unsure if it actually works yet.
Created attachment 356340 [details]
proposed dev-lang/scala-2.10.2.ebuild
This ebuild calls java-pkg_getjars "ant-core,hawtjni-runtime" to fix the
the Class files not found via DEPEND in package.env that were caused by those
dependencies. The remaining errors seem to be something strange about
scala 2.10.2:
* Class files not found via DEPEND in package.env
* scala/tools/partest/nest/RunnerManager$Runner$$anonfun$reportResult$1.class
* scala/tools/nsc/backend/jvm/GenJVM$BytecodeGenerator$$anonfun$computeLocalVarsIndex$1.class
* scala/tools/nsc/interpreter/ByteCode$$anonfun$scalaSigBytesForPath$1.class
* scala/tools/nsc/backend/msil/GenMSIL$BytecodeGenerator$$anonfun$computeLocalVarsIndex$2.class
* scala/tools/nsc/backend/jvm/GenJVM$BytecodeGenerator$$anonfun$addInnerClasses$4.class
* scala/tools/nsc/doc/model/MemberLookup$$anonfun$findExternalLink$2.class
* scala/util/parsing/combinator/PackratParsers$$anonfun$scala$util$parsing$combinator$PackratParsers$$setupLR$2.class
* scala/tools/nsc/doc/Settings$hardcoded$$anonfun$valueClassFilter$1.class
* scala/tools/nsc/backend/jvm/GenASM$JPlainBuilder$$anonfun$computeLocalVarsIndex$1.class
* scala/tools/nsc/typechecker/SuperAccessors$SuperAccTransformer$$anonfun$3.class
* scala/tools/nsc/typechecker/Namers$Namer$$anonfun$templateSig$3.class
* scala/tools/nsc/interpreter/ByteCode$$anonfun$caseParamNamesForPath$1.class
* scala/tools/nsc/symtab/classfile/ClassfileParser$innerClasses$$anonfun$add$1.class
* scala/tools/nsc/symtab/classfile/ClassfileParser$$anonfun$loadClassSymbol$1.class
* scala/tools/nsc/backend/msil/GenMSIL$BytecodeGenerator$$anonfun$computeLocalVarsIndex$1.class
* scala/tools/nsc/typechecker/Namers$Namer$$anonfun$typesFromOverridden$1$1.class
Created attachment 356342 [details] scala jline fails to compile with 2.10.2 The scala jline is different to the java jline: http://dcsobral.blogspot.com.au/2011/03/on-scala-29s-road.html Trying to patch out the scala jline to replace it with the java jline with the patch from fedora: http://pkgs.fedoraproject.org/cgit/scala.git/tree/scala-2.10.0-use_system_jline.patch or actually a hacked version of that since it does not apply to scala 2.10.2, well then it fails to compile, due to upstream changes: locker.comp: [mkdir] Created dir: /var/tmp/portage/dev-lang/scala-2.10.2/work/scala-2.10.2/build/locker/classes/compiler [locker.compiler] Compiling 415 files to /var/tmp/portage/dev-lang/scala-2.10.2/work/scala-2.10.2/build/locker/classes/compiler [locker.compiler] /var/tmp/portage/dev-lang/scala-2.10.2/work/scala-2.10.2/src/compiler/scala/tools/nsc/interpreter/JLineReader.scala:48: error: value readVirtualKey is not a member of JLineReader.this.JLineConsoleReader [locker.compiler] this.readVirtualKey() [locker.compiler] ^ [locker.compiler] one error found BUILD FAILED /var/tmp/portage/dev-lang/scala-2.10.2/work/scala-2.10.2/build.xml:25: The following error occurred while executing this line: /var/tmp/portage/dev-lang/scala-2.10.2/work/scala-2.10.2/build.xml:58: The following error occurred while executing this line: /var/tmp/portage/dev-lang/scala-2.10.2/work/scala-2.10.2/build.xml:979: The following error occurred while executing this line: /var/tmp/portage/dev-lang/scala-2.10.2/work/scala-2.10.2/build.xml:831: The following error occurred while executing this line: /var/tmp/portage/dev-lang/scala-2.10.2/work/scala-2.10.2/build.xml:837: The following error occurred while executing this line: /var/tmp/portage/dev-lang/scala-2.10.2/work/scala-2.10.2/build.xml:791: Compilation failed because of an internal compiler error; see the error output for details. Hence I conclude that trying to replace the scala jline with the java jline is trouble, and would mess up the scala interpreter anyway. Then of course its a chicken and egg problem, the scala compiler needs a scala library to compile it. The scala src includes the source code to this hacked scala jline, so I tried to build it after the scala compiler is built. However it downloads *lots* of jar files to build it and then fails to compile it, as one of the many jars is missing. Created attachment 356362 [details]
proposed dev-lang/scala-2.10.2.ebuild
If there are no objections I intend to push this to portage. Only diff to this version is it requires another symlink for the subslot depend:
dosym "/usr/share/${JAVA_PKG_NAME}/package.env" "/usr/share/${PN}/package.env"
For the 1 test failure I could add
RESTRICT=test
if you like.
(In reply to Kevin Bowling from comment #1) > JDK doesn't need to be hard coded to 1.6 either AFAICT. If this is true it would be cool if the ebulid could change its dependency from virtual/jdk:1.6 to something like >=virtual/jdk:1.6 I was having sandbox problems with the last ebuild, so I added this line in src_compile before the eant calls: export JAVA_OPTS="$JAVA_OPTS -Duser.home=${T}" I'm not sure that's the right way of going about it, but it worked for me. (In reply to Nathan from comment #12) > (In reply to Kevin Bowling from comment #1) > > JDK doesn't need to be hard coded to 1.6 either AFAICT. > > If this is true it would be cool if the ebulid could change its dependency > from virtual/jdk:1.6 to something like >=virtual/jdk:1.6 http://www.scala-lang.org/contribute/hacker-guide.html#build "It is recommended to use Java 1.6 (not 1.7 or 1.8, because they might cause occasional glitches)." In README.rst included in the scala 2.10.2 distribution: ^^^^^^^^^^^^^^^^^^^^^^^^ REQUIREMENTS FOR SABBUS: ^^^^^^^^^^^^^^^^^^^^^^^^ The Scala build system is based on Apache Ant. Most required pre-compiled libraries are part of the repository (in 'lib/'). The following however is assumed to be installed on the build machine: - A Java runtime environment (JRE) or SDK 1.6 or above. - Apache Ant version 1.7.0 or above. - bash (via cygwin for windows) - curl -> I try to avoid the dependency on curl by listing the jars in SRC_URI. (In reply to Nathan from comment #12) > (In reply to Kevin Bowling from comment #1) > > JDK doesn't need to be hard coded to 1.6 either AFAICT. > > If this is true it would be cool if the ebulid could change its dependency > from virtual/jdk:1.6 to something like >=virtual/jdk:1.6 One problem is scala swing with jdk 1.6 or 1.7, discussed here: https://groups.google.com/forum/#!msg/scala-user/4DadtFqt5v4/GyrvnP9B7YQJ (In reply to Mark Wright from comment #14) > (In reply to Nathan from comment #12) > > (In reply to Kevin Bowling from comment #1) > > > JDK doesn't need to be hard coded to 1.6 either AFAICT. > > > > If this is true it would be cool if the ebulid could change its dependency > > from virtual/jdk:1.6 to something like >=virtual/jdk:1.6 > > http://www.scala-lang.org/contribute/hacker-guide.html#build > > "It is recommended to use Java 1.6 (not 1.7 or 1.8, because they might cause > occasional glitches)." oh well that's nasty :/ Created attachment 356668 [details] Thanks to Coy Barnes, add suggested fix (In reply to Coy Barnes from comment #13) > I was having sandbox problems with the last ebuild, so I added this line in > src_compile before the eant calls: > > export JAVA_OPTS="$JAVA_OPTS -Duser.home=${T}" > > I'm not sure that's the right way of going about it, but it worked for me. Thanks, I don't understand the problem or the fix, but I added it to the ebuild, it builds fine in my tests. Created attachment 356670 [details, diff]
jdk 1.7 swing patch
Created attachment 356676 [details, diff] jdk 1.7 swing (In reply to Nathan from comment #16) > (In reply to Mark Wright from comment #14) > > (In reply to Nathan from comment #12) > > > (In reply to Kevin Bowling from comment #1) > > > > JDK doesn't need to be hard coded to 1.6 either AFAICT. > > > > > > If this is true it would be cool if the ebulid could change its dependency > > > from virtual/jdk:1.6 to something like >=virtual/jdk:1.6 > > > > http://www.scala-lang.org/contribute/hacker-guide.html#build > > > > "It is recommended to use Java 1.6 (not 1.7 or 1.8, because they might cause > > occasional glitches)." > > > oh well that's nasty :/ I added a patch based on this Fedora patch (bumped for scala 2.10.2): http://pkgs.fedoraproject.org/cgit/scala.git/tree/scala-2.10.0-java7.patch And this patch from upstream: jdk 1.7 swing patch: SI-7455 Drop dummy param for synthetic access constructor https://issues.scala-lang.org/browse/SI-7455 and in my tests it builds fine with jdk 1.7 (with the 1 same test failure as occurs with jdk 1.6 - also builds with jdk 1.6). So I plan to add it to portage soon, thanks. Fix Bug 450298 - dev-lang/scala-2.10.2 version bump. Thanks to Coy Barnes for reporting the sandbox and fix. Thanks to Nathan, Joel, TomWij, Kevin Bowling, Caster and Chewi for help and suggestions. |