So, I was hearing the pain of Elias and Robert trying to run tests on Windows, so I dual-booted in Windows, and here is my progress report:
* I had to fix the .bat files to fix a typo (if exists should have been if exist) and put quotes around variable expansions to protect against the path containing a space (a frequent occurrence, between Program Files and usernames with spaces). * I had to remove the .exe from asdf-tools' :build-pathname, which was redundant with the .exe added by bundle.lisp, so as not to have asdf-tools.exe.exe * I passed all tests when running using ccl 1.11 for asdf-tools and either ccl or sbcl as the target. But I had to 1- export CCL=/path/to/wx86cl64.exe (and/or just export CCL=wx86cl64.exe and put it in the PATH) (using a ccl.bat script would fail some tests), and 2- use a cygwin window, because ccl fails to (quit) when in a cmd.exe window and has to be killed by the task manager (I once had it fail to quit in cygwin, but could Ctrl-C it dead) (I'll report the bug on the clozure.com site when I get my normal credentials back). * When using sbcl as asdf-tools, some run-program issue prevents invocation of programs, probably due to quoting issues and spaces in executable pathnames.
I'll see if I can kluge my way around SBCL run-program bugs using cmd /s /c. Or muster the courage of fixing SBCL (unlikely considering that when I send patches to SBCL they remain unmerged for years).
-#f
Dear Lispers,
back in Linux. Whew, I was really not at home in Windows, though I reckon it has made a lot of progress since I last used it.
So, for cross-reference, I reported this CCL bug: http://trac.clozure.com/ccl/ticket/1393 And I sent a patch to SBCL as follows, necessary to get (a slightly modified) uiop:run-program to pass all tests: https://bugs.launchpad.net/sbcl/+bug/1503496
I force-pushed my changes on this branch: https://gitlab.common-lisp.net/asdf/asdf/commits/run-program-windows And the merge-request is !52 here: https://gitlab.common-lisp.net/asdf/asdf/merge_requests/52
Everything works perfectly to me using asdf-tools from a cygwin bash with either ccl or sbcl as either asdf-tools or target lisp. I didn't try other implementations, but looking at the code, most of them probably fail badly with respect to run-program on Windows. Using CMD /C properly requires direct access to the CreateProcess string, and no amount of /S /C or such can help undo the quoting properly in the general case.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Nothing is particularly hard if you divide it into small jobs. — Henry Ford
On Sat, Nov 19, 2016 at 7:07 PM, fare windeau fwindeau@gmail.com wrote:
So, I was hearing the pain of Elias and Robert trying to run tests on Windows, so I dual-booted in Windows, and here is my progress report:
- I had to fix the .bat files to fix a typo (if exists should have been if
exist) and put quotes around variable expansions to protect against the path containing a space (a frequent occurrence, between Program Files and usernames with spaces).
- I had to remove the .exe from asdf-tools' :build-pathname, which was
redundant with the .exe added by bundle.lisp, so as not to have asdf-tools.exe.exe
- I passed all tests when running using ccl 1.11 for asdf-tools and either
ccl or sbcl as the target. But I had to 1- export CCL=/path/to/wx86cl64.exe (and/or just export CCL=wx86cl64.exe and put it in the PATH) (using a ccl.bat script would fail some tests), and 2- use a cygwin window, because ccl fails to (quit) when in a cmd.exe window and has to be killed by the task manager (I once had it fail to quit in cygwin, but could Ctrl-C it dead) (I'll report the bug on the clozure.com site when I get my normal credentials back).
- When using sbcl as asdf-tools, some run-program issue prevents invocation
of programs, probably due to quoting issues and spaces in executable pathnames.
I'll see if I can kluge my way around SBCL run-program bugs using cmd /s /c. Or muster the courage of fixing SBCL (unlikely considering that when I send patches to SBCL they remain unmerged for years).
-#f