ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Vogel <>
Subject RE: help - Ant execution search path / Cygwin interaction
Date Mon, 21 May 2001 20:42:00 GMT
In my "bad old gnumake" days, I had a little gnumake macro
to handle the conversion of paths, etc. to unix or windows
format, given a path, it would make sure that the path was
set appropriately for the environment in which gnumake was
running.  If gnumake was running on windows, but in a cygwin
environment, it used the unix form of paths, etc, otherwise
it used the windows form, etc.

Ant tries to "be smart" and do all this for the user.  The 
problem is, when ant is "too smart" and does something it
shouldn't -- you lose flexibility.

In my ideal world, ant would be smart unless told to lay off,
and when told to lay off, it would give me, the build author,
the flexibility to define the behaviour I need.  

Of course, my gnumake macros were long things, unreadable to 
the uninitiated (though they were commented!), but they 
were neatly hidden in a template file, and all you needed 
to know was that you could call ${canonicalpath ${PATH}} and
get the right form, but most users didn't even need to do 
that because those calls were in the generic targets file used
by all makefiles in the tree (most makefiles didn't have local
targets, they just specified what to build from what source and 
the generic templates took care of the rest).


> -----Original Message-----
> From: Daniel Barclay []
> Sent: Monday, May 21, 2001 9:44 AM
> To:; cygwin
> Subject: help - Ant execution search path / Cygwin interaction
> Can anyone help me understand how Ant and Cygwin interact?
> Does Ant's exec task somehow ignore or reset the execution search path
> instead of using the value of the PATH environment variable inherited 
> from the process that ran Ant?
> When I run Ant from CygWin bash, Ant seems to be ignoring or 
> resetting 
> the execution search path.
> Specifically, when I try to run the GNU find command using an 
> exec task, 
> it runs the DOS find command instead.  It seems to ignore my 
> PATH variable.
> My PATH variable in bash lists the CygWin directories first:
>   $ printenv PATH
> /c/tools/emacs-20.7/bin:/usr/bin:/usr/bin:/c/WINNT/system32:/c
> /WINNT:/c/PROGRA~1/Tcl/bin:/c/Daniel/bin:/c/tools/ant-1.3/bin:
> Bash correctly finds the GNU version when I run "find":
>   $ find -version
>   GNU find version 4.1
>   $ 
> When I run "printenv PATH" using ant Ant "exec" task, it 
> shows that the
> process run by Ant has inherited the correct value of the 
> PATH environment
> variable (it has found Cygwin's printenv executable, and 
> printenv prints
> a search path with /usr/bin before WINNT directories):
>      ...
>      [exec] The command attribute is deprecated. Please use 
> the executable attribute and nested arg
> elements.
>      [exec] Myos = Windows NT
>      [exec] printenv PATH
>      [exec]
> /c/tools/emacs-20.7/bin:/c/tools/emacs-20.7/bin:/usr/local/bin
> :/usr/bin:/usr/bin:/c/WINNT/system32:/c/WINNT:/c/PROGRA~1/Tcl/
> bin:/c/Daniel/bin:/c/tools/ant-1.3/bin:/c/tools/jdk1.3/bin:/c/
>      ...
> However, when I run "find" using an exec task, it's obvious 
> that Ant runs
> the DOS version:
>      ...
>      [exec] The command attribute is deprecated. Please use 
> the executable attribute and nested arg
> elements.
>      [exec] Myos = Windows NT
>      [exec] find -version
>      [exec] FIND: Parameter format not correct
>      [exec] Result: 2
>      ...
> So if Ant inherits the correct variable of PATH, as evidenced 
> above, why 
> doesn't Ant find the Cygwin version of find instead of the 
> DOS version?
> Cygwin environment variables seem to propagate into spawned 
> DOS shell just
> fine (starting in bash, runnning "export x=y", "cmd", "set x" 
> shows "x=y").
> The Cygwin PATH variable seems to propagate fine (starting in 
> bash, "cmd", 
> "find -version" runs GNU find).
> Does Ant (e.g., Java) somehow reset the environment to 
> Windows/DOS defaults
> when it starts an executable?  Does it do anything else that 
> might cause
> this behavior?
> Thanks,
> Daniel
> -- 
> Daniel Barclay
> Digital Focus

View raw message