Mariusz Nowostawski <[EMAIL PROTECTED]> 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
