-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expunged the .net backend. #1718
Conversation
It lives on in a branch born from this commit's parent. It's abrupt; no attempt is made to offer a "smooth transition" for the serious msil userbase, population zero. If anyone feels very strongly that such a transition is necessary, I will be happy to talk you into feeling differently.
Started jenkins job pr-rangepos at https://scala-webapps.epfl.ch/jenkins/job/pr-rangepos/1089/ |
jenkins job pr-rangepos: Success - https://scala-webapps.epfl.ch/jenkins/job/pr-rangepos/1089/ |
Started jenkins job pr-scala-testsuite-linux-opt at https://scala-webapps.epfl.ch/jenkins/job/pr-scala-testsuite-linux-opt/1799/ |
jenkins job pr-scala-testsuite-linux-opt: Success - https://scala-webapps.epfl.ch/jenkins/job/pr-scala-testsuite-linux-opt/1799/ |
@@ -669,9 +667,6 @@ LOCAL REFERENCE BUILD (LOCKER) | |||
<pathelement location="${build-locker.dir}/classes/library"/> | |||
</classpath> | |||
</javac> | |||
<!-- NOTE: Potential problem with maximal command line length on Windows | |||
(32768 characters for XP, since executed with Java's "exec"). See | |||
src/build/msil.xml in msil branch for more details. --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be interesting to know where that msil.xml
lives to learn about maximal command line length.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- <!--
- NOTE: Command line length hell on windows. The maximal command line length on
- Windows XP or later is 8191 characters (http://support.microsoft.com/kb/830473).
-
- BUT: this only applies for processes executed directly in the shell, which is NOT
- the case by default when using ant's "exec" command; this one uses the Java VM's
- execution facilities which allow larger command lines. Testing gives:
- - Windows XP: 32768 characters
-
- When the parameter (vmlauncher="false") is specified, the <exec/> command uses
- the udnerlying shell, and the smaller limit applies.
-
- The call to ilasm produces lots of output, which could be avoided using
- (spawn="true"). This seems to work wrt to the character limit (32768), but is
- probably not the best solution since it's incompatible with (failonerror),
- and does not produce any output at all.
- -->
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it will be helpful to add this comment to build.xml.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I started to comply, but stopped when I realized how little of it made sense. Can you maybe reformulate the comment to have some meaning in the context of the build as it is today? Because a) we never use ant's 'exec' task for anything where max command line length could possibly come up and b) ilasm?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah you're right. Looks like all execs with non-trivial command lines are done in our custom tasks.
let me shed a tear. 😿 |
lgtm. Expect some minor merge conflicts with my excision of the GenJVM backend. |
There, there, sad kitty. There, there. |
uh-oh, I seem to already have merged this into oblivion -- let's wait until #1717 is merged, rebase this one and merge it before it gets another chance to go all stale on us |
Superseded by #1724. |
It lives on in a branch born from this commit's parent.
It's abrupt; no attempt is made to offer a "smooth transition"
for the serious msil userbase, population zero. If anyone feels
very strongly that such a transition is necessary, I will be
happy to talk you into feeling differently.