Mariusz Nowostawski <[EMAIL PROTECTED]> wrote:
> 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,
right, at least for you and me 8-)
> however I do not like to use this 'limit' argument to artificially
> control length of arguments for particular OS.
Actually, as Nico pointed out, we've decided to use a very radical
limit of 4096 bytes that POSIX defines and that works across all
platforms (as far as we know) in the jikes/jvc case. We didn't want to
support a map of ${os.name} to acceptable length of command lines, I
still think this has been the right decision.
> One proposal given by Stefan is: a) just fail if the command line is
> too long for a given OS
right.
> there is of course opposite alternative: b) split the command if the
> argument list is too long.
if you know of a good way to find out - or fall back to 4096.
> 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.
This is getting quite complicated, isn't it 8-).
We'd have three attributes that influence each other - quite difficult
to explain. If we want to follow that route, we'd better deprecate
parallel in favour of limit="1" and limit="NONE".
enablesplit should be set to false by default IMHO - keep things
explicit, i.e. apply magic only if the user asks for it.
> Also, this length limit applies only to a limited number of OSes,
Not true at all. It applies to (almost?) every OS, the limit is just
different.
Stefan
