ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mariusz Nowostawski <mari...@marni.otago.ac.nz>
Subject Re: long command lines from execon with parallel=true
Date Tue, 23 Jan 2001 09:39:06 GMT
On 23 Jan 2001, Stefan Bodewig wrote:
> 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.

Right. We agree that limiting the length inside a target does not make
much sense. We also agree that limiting the number of arguments makes
sense, as: 
* it solves nicely (3)
* it could be (mis)used to control the length of arguments to execon
I am fine with both points above, however I do not like to use this
'limit' argument to artificially control length of arguments for
particular OS.

We have one thing to solve: when execon target should "just
fail", and when it should split. It depends of course only on the type
of the executable execon is working with.
One proposal given by Stefan is:
a) just fail if the command line is too long for a given OS

there is of course opposite alternative:
b) split the command if the argument list is too long.
`
As pointed by Stefan, b) has some problems for executables which can only
handle single call with all the arguments at once. But to me, b) applies
well to most of the cases, like all sorts of file preprocessing, compiling
JSP, IDLs etc etc. and as such could be a valueable feature. 


My proposal:

Add yet another argument, let say 'enablesplit' with default value
"true" or "false" which controls b) and a) respectively in case the
argument list exceeded a limit for the given OS. 
In such case, ppl compiling JSP would set enablesplit to true and do not
bother with relative path length and windows argument list length limits. 

ppl using tar-like executables would set enablesplit to false, which in
case of too long argument list would "just fail".

That would be nicer for developers. Splitting artificially JSP
compilation into multiple execon calls, especially, if it is not sure how
many arguments one can pass at once taking into account some relative
path lengths, is not very appealing to me.  Also, this length limit
applies only to a limited number of OSes, and making special tricks in
build file just to enable efficient execution on only one OS seems to me
too nasty.

best regards
Mariusz


Mime
View raw message