Before I can start actually fixing the TAGS target, I figured making it run under win32 at all would help :)
The problem is that with parallel="true", ant seems to send too many parameters to CreateProcess, which then sobs about error=87: the parameter is invalid.
The attached patch addresses this issue by specifying maxparallel to prevent argument list overflow, and appending the results to the TAGS file incrementally. This results in two invokations to etags, rather than one.
Does this behave as expected for you Mark?
Cheers, Matt
On 7/17/10 12:47 AM, Matt Seddon wrote:
Before I can start actually fixing the TAGS target, I figured making it run under win32 at all would help :)
The problem is that with parallel="true", ant seems to send too many parameters to CreateProcess, which then sobs about error=87: the parameter is invalid.
The attached patch addresses this issue by specifying maxparallel to prevent argument list overflow, and appending the results to the TAGS file incrementally. This results in two invokations to etags, rather than one.
For win32 invocations of TAGS, I use the one packaged with Xemacs in Cygwin (although I use it with GNU Emacs), which doesn't produce the error which you encountered. This makes some amount of sense as it is the DOS command prompt which has a limit on total command length from what I remember, whereas cygwin is running bash. Could you give a few more details about your win32 development environment? In such a development environment, would you plausibly have an editor that could use the TAGS table?
Your patch seems to work fine under OS X, so I would have no trouble with committing it (I might change '-a' to '--append' to match the other argument) if you wish.
On 17/07/2010 07:39, Mark Evenson wrote:
Could you give a few more details about your win32 development environment? In such a development environment, would you plausibly have an editor
that
could use the TAGS table?
I'm running netbeans, which I use for java development, the mingw gnu-emacs build for slime/lisp/general editing, and invoking ant from either a win32 command window or within eshell. I'd guess anyone who is working in mingw rather than cygwin could potentially run into this issue.
Your patch seems to work fine under OS X, so I would have no trouble with committing it (I might change '-a' to '--append' to match the other argument) if you wish.
Sure, that seems appropriate.
While I'm messing with the build.xml, I'd also like to add an initial delete step to the ansi tests that removes ../ansi-tests/scratch. This will prevent ENSURE-DIRECTORIES-EXIST.8 from failing after a second run, unless there is a reason not too.
On 7/17/10 9:11 AM, Matt Seddon wrote:
[…]
Your patch seems to work fine under OS X, so I would have no trouble with committing it (I might change '-a' to '--append' to match the other argument) if you wish.
Sure, that seems appropriate.
Committed [as r12808][1].
[1]: http://trac.common-lisp.net/armedbear/changeset/12808
On 7/17/10 9:11 AM, Matt Seddon wrote: […]
While I'm messing with the build.xml, I'd also like to add an initial delete step to the ansi tests that removes ../ansi-tests/scratch. This will prevent ENSURE-DIRECTORIES-EXIST.8 from failing after a second run, unless there is a reason not too.
The test suites are all wrapped in ASDF definitions, so one can easily run the tests from within an ABCL session possibly interactively changing behavior without needing a recompile.
The UNIX version of ANSI-COMPILED/ANSI-INTERPRETED invokes "make clean" on the makefile provided for by the tests. Attached is a patch that extends the win32 version's use of 'erase' to include all the targets found in that target. If you can test that this eliminates your test failure, I'll commit it.
On 7/17/10 10:53 AM, Mark Evenson wrote: […]
The UNIX version of ANSI-COMPILED/ANSI-INTERPRETED invokes "make clean" on the makefile provided for by the tests. Attached is a patch that extends the win32 version's use of 'erase' to include all the targets found in that target. If you can test that this eliminates your test failure, I'll commit it.
It turns out "ERASE" is a something like a DOS shell primitive, and can't be invoked by RUN-SHELL-COMMAND (who knew DOS could get *more* primitive).
With help from Matt, I have [committed in 12811][1] a removal of intermediate ANSI files via DELETE-FILE, so this should now work on all platforms.
[1]: http://trac.common-lisp.net/armedbear/changeset/12811
On 17 July 2010 15:08, Mark Evenson evenson@panix.com wrote:
It turns out "ERASE" is a something like a DOS shell primitive, and can't be invoked by RUN-SHELL-COMMAND (who knew DOS could get *more* primitive).
Oh. It must be a command internal to the command interpreter (cmd.exe, or in the days of yore, command.com). We would need to invoke the interpreter specificly and pass erase as the command to run.
armedbear-devel@common-lisp.net
-
Mark Evenson -
Matt Seddon -
Ville Voutilainen