Scala Programming Language
  1. Scala Programming Language
  2. SI-6268

scalac ant task does not accept fork="true" in 2.10.0-M7

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: Scala 2.10.0-M7, Scala 2.10.0
    • Component/s: None
    • Labels:
      None

      Description

      The scalac task does not accept fork="true" in Scala 2.10.0-M7. It does accept fork="false".

      compile-main:
      [scalac] Compiling 196 source files to /Users/bv/nobkp/delus/r18for210M3/target/jar_contents
      [scalac] Compiling 4 source files to /Users/bv/nobkp/delus/r18for210M3/target/jar_contents
      [scalac] Compiling 0 scala and 3 java source files to /Users/bv/nobkp/delus/r18for210M3/target/jar_contents
      [scalac] Usage: scalac <options> <source files>
      [scalac] where possible standard options include:
      [scalac] -Dproperty=value Pass -Dproperty=value directly to the runtime system.
      [scalac] -J<flag> Pass <flag> directly to the runtime system.
      [scalac] -P:<plugin>:<opt> Pass an option to a plugin
      [scalac] -X Print a synopsis of advanced options.
      [scalac] -bootclasspath <path> Override location of bootstrap class files.
      [scalac] -classpath <path> Specify where to find user class files.
      [scalac] -d <directory|jar> destination for generated classfiles.
      [scalac] -dependencyfile <file> Set dependency tracking file.
      [scalac] -deprecation Emit warning and location for usages of deprecated APIs.
      [scalac] -encoding <encoding> Specify character encoding used by source files.
      [scalac] -explaintypes Explain type errors in more detail.
      [scalac] -extdirs <path> Override location of installed extensions.
      [scalac] -feature Emit warning and location for usages of features that should be imported explicitly.
      [scalac] -g:<level> Set level of generated debugging info. (none,source,line,vars,notailcalls) default:vars
      [scalac] -help Print a synopsis of standard options
      [scalac] -javabootclasspath <path> Override java boot classpath.
      [scalac] -javaextdirs <path> Override java extdirs classpath.
      [scalac] -language:<feature> Enable one or more language features.
      [scalac] -no-specialization Ignore @specialize annotations.
      [scalac] -nobootcp Do not use the boot classpath for the scala jars.
      [scalac] -nowarn Generate no warnings.
      [scalac] -optimise Generates faster bytecode by applying optimisations to the program
      [scalac] -print Print program with Scala-specific features removed.
      [scalac] -sourcepath <path> Specify location(s) of source files.
      [scalac] -target:<target> Target platform for object files. All JVM 1.5 targets are deprecated. (jvm-1.5,jvm-1.5-fjbg,jvm-1.5-asm,jvm-1.6,jvm-1.7,msil) default:jvm-1.6
      [scalac] -toolcp <path> Add to the runner classpath.
      [scalac] -unchecked Enable additional warnings where generated code depends on assumptions.
      [scalac] -uniqid Uniquely tag all identifiers in debugging output.
      [scalac] -usejavacp Utilize the java.class.path in classpath resolution.
      [scalac] -verbose Output messages about what the compiler is doing.
      [scalac] -version Print product version and exit.
      [scalac] @<file> A text file containing compiler arguments (options and source files)
      [scalac]
      [scalac] Deprecated settings:
      [scalac] -make:<policy> Recompilation detection policy (all,changed,immediate,transitive,transitivenocp) default:all
      [scalac] deprecated: this option is unmaintained. Use sbt or an IDE for selective recompilation.
      [scalac]

      The branch you can use to reproduce the problem is:

      https://scalatest.googlecode.com/svn/branches/r18for210M7

      Just say "ant test" and it will happen very quickly.

        Activity

        Hide
        Josh Suereth added a comment -

        Its appears like you're sending only java sources to Scalac when there is no scala sources. Can you validate this is the behavior? I think that's why it's not working.

        Show
        Josh Suereth added a comment - Its appears like you're sending only java sources to Scalac when there is no scala sources. Can you validate this is the behavior? I think that's why it's not working.
        Hide
        Josh Suereth added a comment - - edited

        Ok, so this simple test works:

        <?xml version="1.0" encoding="UTF-8"?>
        
        <project name="test-simple" default="compile">
          <description>
        Super simple test for Scala
        
          <target name="init">
             <!-- Define project CLASSPATH. -->
            <property name="base.dir" value="../../.."/>
            <property name="pack.dir" value="${base.dir}/build/pack/"/>
            <property name="build.dir" value="classes"/>
            <property name="src.dir" value="src"/>
            <path id="scala.classpath">
              <fileset dir="${pack.dir}/lib/"> <include name="*.jar" /> </fileset>
            </path>
        
            <!-- Define scala compiler, scaladoc, etc command -->
            <taskdef resource="scala/tools/ant/antlib.xml">
              <classpath refid="scala.classpath" />
            </taskdef>
          </target>
        
          <target name="compile" depends="init">
            <mkdir dir="${build.dir}"/>
        
            <scalac srcdir="${src.dir}" destdir="${build.dir}"
                    classpathref="scala.classpath" fork="true">
              <include name="**/*.scala"/>
            </scalac>
          </target>
        </project>
        

        Time to investigate if the "too many argument" handling is broken.

        Show
        Josh Suereth added a comment - - edited Ok, so this simple test works: <?xml version="1.0" encoding="UTF-8"?> <project name="test-simple" default="compile"> <description> Super simple test for Scala <target name="init"> <!-- Define project CLASSPATH. --> <property name="base.dir" value="../../.."/> <property name="pack.dir" value="${base.dir}/build/pack/"/> <property name="build.dir" value="classes"/> <property name="src.dir" value="src"/> <path id="scala.classpath"> <fileset dir="${pack.dir}/lib/"> <include name="*.jar" /> </fileset> </path> <!-- Define scala compiler, scaladoc, etc command --> <taskdef resource="scala/tools/ant/antlib.xml"> <classpath refid="scala.classpath" /> </taskdef> </target> <target name="compile" depends="init"> <mkdir dir="${build.dir}"/> <scalac srcdir="${src.dir}" destdir="${build.dir}" classpathref="scala.classpath" fork="true"> <include name="**/*.scala"/> </scalac> </target> </project> Time to investigate if the "too many argument" handling is broken.
        Hide
        Josh Suereth added a comment -

        I'm unable to reproduce your build problem local on your full build and also with the small sample included. This is on Ubuntu.

        Could you have a stale or malformed caching isssue?

        Show
        Josh Suereth added a comment - I'm unable to reproduce your build problem local on your full build and also with the small sample included. This is on Ubuntu. Could you have a stale or malformed caching isssue?
        Hide
        Josh Suereth added a comment -

        Ok tracked it down to a broken refactoring here: https://github.com/scala/scala/commit/963aabbeb4

        Show
        Josh Suereth added a comment - Ok tracked it down to a broken refactoring here: https://github.com/scala/scala/commit/963aabbeb4
        Show
        Josh Suereth added a comment - https://github.com/scala/scala/pull/1288
        Hide
        Paul Phillips added a comment -

        FYI, I went that way because unparsing -i "foo bar.scala" as in the pull request will give us -i:foo bar.scala. Not that the world will be full of workingness when you have spaces in your path.

        Show
        Paul Phillips added a comment - FYI, I went that way because unparsing -i "foo bar.scala" as in the pull request will give us -i:foo bar.scala. Not that the world will be full of workingness when you have spaces in your path.
        Hide
        Josh Suereth added a comment -

        The issue is that your patch needed to merge the list of string into one:

        def unparse = if(values.isEmpty) Nil 
                      else name :: (value mkString " ") :: Nil
        

        I went the less code route, assuming it still parses. Like I said, I couldn't tell if we had automated tests, I just validated against scalatest and the ant build in that commit. I think we should add some partest setting tests so we avoid breaking each other!

        Show
        Josh Suereth added a comment - The issue is that your patch needed to merge the list of string into one: def unparse = if(values.isEmpty) Nil else name :: (value mkString " ") :: Nil I went the less code route, assuming it still parses. Like I said, I couldn't tell if we had automated tests, I just validated against scalatest and the ant build in that commit. I think we should add some partest setting tests so we avoid breaking each other!
        Hide
        Paul Phillips added a comment -

        "I think we should add some partest setting tests so we avoid breaking each other!"

        Well yeah, we should have done that five years ago. As always, the obstacle to script tests (which is the meaningful way to test command line properties - from the command line) is windows. Whenever I have tried to check in anything in this area, I have had to revert it. I no longer try. For the glory of windows, we have no tests here for anyone.

        Show
        Paul Phillips added a comment - "I think we should add some partest setting tests so we avoid breaking each other!" Well yeah, we should have done that five years ago. As always, the obstacle to script tests (which is the meaningful way to test command line properties - from the command line) is windows. Whenever I have tried to check in anything in this area, I have had to revert it. I no longer try. For the glory of windows, we have no tests here for anyone.
        Hide
        Josh Suereth added a comment -

        That I can fix. Since we have the pull request validation now, we can set up tests which only run on "platform foo" and be reasonably assured they'll prevent bad code from entering the repo.

        I'll put that on the list of things to fix in partest.

        Show
        Josh Suereth added a comment - That I can fix. Since we have the pull request validation now, we can set up tests which only run on "platform foo" and be reasonably assured they'll prevent bad code from entering the repo. I'll put that on the list of things to fix in partest.

          People

          • Assignee:
            Josh Suereth
            Reporter:
            Bill Venners
          • Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development