ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: emacs cygwin compile.el next-error fails with Ant (Was Re: [BUG])
Date Thu, 24 Jul 2003 08:08:15 GMT
On 24 Jul 2003, Mark Evenson <> wrote:

> When the build.compiler.emacs property is true AND Ant is running
> under cygwin, the meaning is clear: Ant should emit the UNIX style
> paths that cygwin emacs expects to parse.

I'm not sure.  What about the non-Cygwin versions of GNU Emacs and
XEmacs?  I guess they'll work with Unix like pathes fine, but I'm not
sure whether they'll deal with the virtual file system cygwin uses to
map drives (AFAIU).

I vaguely recall (I'm an XEmacs user, but not a Windows user, so take
what I say with a big grain of salt) some lisp methods mentioned on
the JDEE list that would do the file name translation for you.  The
correct solution for you would be some elisp IMHO - and I'm rather
sure the function you need will be there already.

> Unfortunately there doesn't seem to be a property (checked via
> <echoproperties>) that tells Ant it is running inside cygwin.

<cvspass> checks for cygwin.user.home.  Maybe you could hook into

> And of course, since the error messages from the <javac> task come
> straight from the compiler (which, as a native win32 task, will only
> work running with Win32 path.separator value), this means an
> additional transformation of the compilation message stream which I
> can't see a great place to hook into the Ant codebase.

Here is the biggest problem IMHO.  The compiler errors come straight
from javac's output stream into Ant's logging system.  The place to
plug in to would be a custom BuildListener/Logger.

I'm not sure that brute force replacing everything that looks like a
file name would be a good idea either.  And the same problem certainly
applies to things like <rmic> and probably even <xslt>.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message