ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: long command lines from execon with parallel=true
Date Tue, 23 Jan 2001 09:10:07 GMT
Mariusz Nowostawski <mariusz@marni.otago.ac.nz> wrote:

> Limiting a length is such an artificial and OS-dependent-only thing,
> that I would rather not make it a parameter of a build target, but
> place it (i.e. hardcode it) inside the execon implementation for a
> particular OS.

No. This could cause a whole bunch of new problems. There are at least
four different use cases for <execon> and hardcoding an os-specific
limit would break number (4) down there:

(1) the invoked executable can only deal with a single file - use
parallel=false.

(2) the invoked executable can deal with a single file or multiple
files, <chmod> for example - here you can set parallel to whatever
value you want and we could add a limit="NUMBER" attribute which
wouldn't break anything.

(3) the invoked executable can only deal with a limited number of
files - you won't win anything by restricting the length of the
command line, while restricting the number of files is the way to go.

(4) the invoked command has to be invoked with all files at once, no
matter what - something like "tar cf" where subsequent exec's must be
"tar rf", there will most certainly be a better example. Here an
os-specific limit would produce errors (incomplete archive) that would
be difficult to spot.

So my proposal:

Add a limit attribute that specifies the number of files to process in
parallel. Make it infinite by default (as parallel is true by
default), make parallel="false" an alias for limit="1". If the
command line would be too long (externalize the code from the Jikes
compilation process), just fail with a reasonable error message.

Stefan

Mime
View raw message