Scalac ant task fix + sabbus build fix for windows

Everyone -

I'm including two patches.  The first is mostly innocuous.  I've modified the forking feature of the scalac ant task to make use of the new @<file> argument.  This fixes the command-line length limitation issues on windows.  The only "cheat" I've made i to escape arguments that have spaces in them with "s.  What happens if an argument has " and spaces?  I'm not quite sure.  I'd actually like to adjust the @ functionality to have a different grammar (if possible).  It would be very easy for maven/ant etc. if the syntax was simply:

argfile :=  args*
arg = non-eol+  eol
eol = '\r' | '\n' | "\r\n"
non-eol = any character but \r \n

Anyway, in the meantime, all my projects are building with the argument escaping logic I've chosen.

The second patch is a little more aggressive.  I've taken every location in sabbus where "scalacfork" was used, and instead modified to use the scalac task (from starr).  The one location where scalac was used, I'm importing scalac with a different name (pack-scalac).  With a starr built with the above ant fix, and applying this second patch in windows, you can now build successfully from any directory (no longer command-line length errors!).  I'd really love to see this patch (or something like it) make it in soon.   I also don't think we need to maintain scalac and scalacfork as scalacfork is redundant now.

I'd like to hear back on these patches individually.  If I hear nothing on the scalac ant task fix by wed. I'd like to commit it into trunk.  I'd like to hear some positive feedback on the sabbus changes (at least a few from EPFL) before committing to trunk.

Thanks!
-Josh

Excellent work.  Is there a build server that'll help make sure Scala continues building on Windows after your commit[s]?

2009/5/3 Josh Suereth <joshua.suereth@gmail.com>

Everyone -

I'm including two patches.  The first is mostly innocuous.  I've modified the forking feature of the scalac ant task to make use of the new @<file> argument.  This fixes the command-line length limitation issues on windows.  The only "cheat" I've made i to escape arguments that have spaces in them with "s.  What happens if an argument has " and spaces?  I'm not quite sure.  I'd actually like to adjust the @ functionality to have a different grammar (if possible).  It would be very easy for maven/ant etc. if the syntax was simply:

argfile :=  args*
arg = non-eol+  eol
eol = '\r' | '\n' | "\r\n"
non-eol = any character but \r \n

Anyway, in the meantime, all my projects are building with the argument escaping logic I've chosen.

The second patch is a little more aggressive.  I've taken every location in sabbus where "scalacfork" was used, and instead modified to use the scalac task (from starr).  The one location where scalac was used, I'm importing scalac with a different name (pack-scalac).  With a starr built with the above ant fix, and applying this second patch in windows, you can now build successfully from any directory (no longer command-line length errors!).  I'd really love to see this patch (or something like it) make it in soon.   I also don't think we need to maintain scalac and scalacfork as scalacfork is redundant now.

I'd like to hear back on these patches individually.  If I hear nothing on the scalac ant task fix by wed. I'd like to commit it into trunk.  I'd like to hear some positive feedback on the sabbus changes (at least a few from EPFL) before committing to trunk.

Thanks!
-Josh

http://scala-webapps.epfl.ch/hudson/

Notice the hackery (printed in the log file) to get the command-line path short:http://scala-webapps.epfl.ch/hudson/job/scala-nightly-windows/175/console

While its a nice temporary fix, My commit makes such magikery unnecessary.


On Sun, May 3, 2009 at 7:18 AM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

Excellent work.  Is there a build server that'll help make sure Scala continues building on Windows after your commit[s]?

2009/5/3 Josh Suereth <joshua.suereth@gmail.com>

Everyone -

I'm including two patches.  The first is mostly innocuous.  I've modified the forking feature of the scalac ant task to make use of the new @<file> argument.  This fixes the command-line length limitation issues on windows.  The only "cheat" I've made i to escape arguments that have spaces in them with "s.  What happens if an argument has " and spaces?  I'm not quite sure.  I'd actually like to adjust the @ functionality to have a different grammar (if possible).  It would be very easy for maven/ant etc. if the syntax was simply:

argfile :=  args*
arg = non-eol+  eol
eol = '\r' | '\n' | "\r\n"
non-eol = any character but \r \n

Anyway, in the meantime, all my projects are building with the argument escaping logic I've chosen.

The second patch is a little more aggressive.  I've taken every location in sabbus where "scalacfork" was used, and instead modified to use the scalac task (from starr).  The one location where scalac was used, I'm importing scalac with a different name (pack-scalac).  With a starr built with the above ant fix, and applying this second patch in windows, you can now build successfully from any directory (no longer command-line length errors!).  I'd really love to see this patch (or something like it) make it in soon.   I also don't think we need to maintain scalac and scalacfork as scalacfork is redundant now.

I'd like to hear back on these patches individually.  If I hear nothing on the scalac ant task fix by wed. I'd like to commit it into trunk.  I'd like to hear some positive feedback on the sabbus changes (at least a few from EPFL) before committing to trunk.

Thanks!
-Josh

Sorry, read "commit" as "potential commit" or "patch"

On Sun, May 3, 2009 at 7:49 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:

http://scala-webapps.epfl.ch/hudson/

Notice the hackery (printed in the log file) to get the command-line path short:http://scala-webapps.epfl.ch/hudson/job/scala-nightly-windows/175/console

While its a nice temporary fix, My commit makes such magikery unnecessary.


On Sun, May 3, 2009 at 7:18 AM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

Excellent work.  Is there a build server that'll help make sure Scala continues building on Windows after your commit[s]?

2009/5/3 Josh Suereth <joshua.suereth@gmail.com>

Everyone -

I'm including two patches.  The first is mostly innocuous.  I've modified the forking feature of the scalac ant task to make use of the new @<file> argument.  This fixes the command-line length limitation issues on windows.  The only "cheat" I've made i to escape arguments that have spaces in them with "s.  What happens if an argument has " and spaces?  I'm not quite sure.  I'd actually like to adjust the @ functionality to have a different grammar (if possible).  It would be very easy for maven/ant etc. if the syntax was simply:

argfile :=  args*
arg = non-eol+  eol
eol = '\r' | '\n' | "\r\n"
non-eol = any character but \r \n

Anyway, in the meantime, all my projects are building with the argument escaping logic I've chosen.

The second patch is a little more aggressive.  I've taken every location in sabbus where "scalacfork" was used, and instead modified to use the scalac task (from starr).  The one location where scalac was used, I'm importing scalac with a different name (pack-scalac).  With a starr built with the above ant fix, and applying this second patch in windows, you can now build successfully from any directory (no longer command-line length errors!).  I'd really love to see this patch (or something like it) make it in soon.   I also don't think we need to maintain scalac and scalacfork as scalacfork is redundant now.

I'd like to hear back on these patches individually.  If I hear nothing on the scalac ant task fix by wed. I'd like to commit it into trunk.  I'd like to hear some positive feedback on the sabbus changes (at least a few from EPFL) before committing to trunk.

Thanks!
-Josh