title: Speed of scala's ant fsc task
body: <p>I have an ant file I use to compile my scala project. I'm using fsc which works wonders to avoid the 2~3 seconds my core 2 needs to just load the compiler.<br>
  My problem is: the ant <code>fsc</code> task does incur the same 2~3 seconds penalty, to the best of my knowledge. It is pretty annoying, because there is fsc specifically for this reason. It is even more annoying since it's really starting time and not processing time, so I have to wait 3 seconds on the fsc task even when there is nothing to re-compile. Each and every time, it becomes aggravating.</p>
  
  <p>My investigation seems to show that most the time is spent reading scala-compiler.jar. Indeed, it makes sense the <code>scalac</code> and <code>fsc</code> tasks need this, since they run the compiler directly. Besides, removing scala-compiler.jar from the classpath of the ant task results, of course, in the task failing for lack of the dependency.<br>
  Logically speaking, the <code>fsc</code> task is only connecting to the compilation dæmon I suppose, so it shouldn't need that dependency, but I suppose it's about how it's implemented (the fsc task inherits from the scala task). Maybe it will come in a next version.</p>
  
  <p>The solution I am looking at at the moment is, rewrite my fsc task as an apply task and invoke fsc manually. I won't have the delay then. It's just a pity to have to redo manually the work that the tasks included with scala were specifically written to handle.</p>
  
  <p>Does anyone have experience with this problem? Is anything wrong in my analysis? And can you suggest a better solution than the one I am planning to implement?</p>
  
  <p>For reference, here is what my task looks like (yes, it compiles an android project):</p>
  
  <pre><code>&lt;target name="compile-scala" description="Compile scala files"&gt;
    &lt;taskdef resource="scala/tools/ant/antlib.xml" classpath="${scala-library.jar}:${scala-compiler.jar}" /&gt;
    &lt;mkdir dir="${out.classes.absolute.dir}" /&gt;
    &lt;fsc encoding="utf-8" deprecation="on" destdir="${out.classes.absolute.dir}"&gt;
      &lt;src&gt;
        &lt;dirset dir="." includes="src"/&gt;
        &lt;dirset dir="." includes="gen"/&gt;
      &lt;/src&gt;
      &lt;classpath&gt;
        &lt;pathelement location="${android.jar}" /&gt;
        &lt;fileset dir="${sdk.dir}/tools/lib" includes="*.jar" /&gt;
      &lt;/classpath&gt;
    &lt;/fsc&gt;
  &lt;/target&gt;
  </code></pre>
  
  <p><strong>Edit</strong>: Here is what the task with apply looks like. It seems to work. It is however quite unsatisfying, so the question still holds.</p>
  
  <pre><code>&lt;target name="fast-compile-scala"
      description="Compile scala files without loading the compiler inside ant"&gt;
    &lt;mkdir dir="${out.classes.absolute.dir}" /&gt;
    &lt;apply executable="fsc" failonerror="true" parallel="true"&gt;
      &lt;arg value="-encoding" /&gt;
      &lt;arg value="utf-8" /&gt;
      &lt;arg value="-deprecation" /&gt;
      &lt;arg value="-dependencyfile" /&gt;
      &lt;arg value="${out.classes.absolute.dir}/${scala.deps}" /&gt;
      &lt;arg value="-g:vars" /&gt;
      &lt;arg value="-d" /&gt;
      &lt;arg value="${out.classes.absolute.dir}" /&gt;
      &lt;arg value="-make:transitivenocp" /&gt;
      &lt;arg value="-classpath" /&gt;
      &lt;arg value="${android.jar}:${out.classes.absolute.dir}" /&gt;
      &lt;!-- &lt;arg value="-optimize" /&gt; --&gt;
      &lt;!-- &lt;arg value="-verbose" /&gt; --&gt;
      &lt;!-- &lt;arg value="-explaintypes" /&gt; --&gt;
      &lt;fileset dir="src" includes="**/*.scala" /&gt;
      &lt;fileset dir="src" includes="**/*.java" /&gt;
      &lt;fileset dir="gen" includes="**/*.java" /&gt;
    &lt;/apply&gt;
  &lt;/target&gt;
  </code></pre>
  
  <p><strong>Edit again</strong>:
  The above works, but I find it has a quite severe limitation. When the number of files grow, the above task is limited by the number of arguments and/or the length of the command line. Under linux or mac OS with a good shell you can go quite a way without hitting this wall, but under windows a couple dozen files is all it takes to prevent the above from working. Adding an option to specify files as relative paths instead of absolute gives some breath, but not much. Splitting files in several commands according to dependencies is not a realistic option for it is a quite heavy task and needs to be updated whenever the file structure changes. So while for small projects the above will mostly solve the issue, it won't help for any project of a respectable size...</p>