You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Nico Seessle <ni...@seessle.de> on 2000/09/26 10:59:53 UTC

Commandline-Handling for external compilation

I want to get back on this topic as it's still unsolved and I think it
should be before Ant 1.2 (will people complain less "Ant will not work for
me if I compile this many files").

The problem:
Different OS accept different max. length for the commandline passed to an
external compiler. If Ant knows it's going over this limit it will use a
temporary file and pass this file to the compiler via @tempfile. Currently
this is only handled for Windows.

Currently known limits are:

Windows 32k (only 4k if a directory change is required and JDK < 1.3)
Linux about 100k (including environment)
AIX  about 20k (including environment)
POSIX Standard seems to be 4k

I can currently think of three ways solving this problem:

1. Always use a limit of 4k
2. Always use a limit of 4k except you know the OS you are currently running
on has a higher limit and hard-code this in Javac (will require a change to
the source for every 'new' OS)
3. Read the known limit's from a property file and check against these
4. Option 1 and allow people to override using a property if they know
better
5. Option 2 for 'most often used OS' and allow people for their own OS if
they know better
6. Don't change it (not really a 'solution')

What do you think?

Nico



Re: Commandline-Handling for external compilation

Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "DW" == Dirk Weigenand <Di...@oracle.com> writes:

 DW> Nico Seessle wrote:

 >> I can currently think of three ways solving this problem:

(became 6 ;-)

 DW> 7. Try to compile and check if there is an exception thrown that
 DW> states that the comandline was too long and then write the files
 DW> to compile into a temporary file and rerun the compile.

It could be difficult to identify an exception as one of the type
CommandLineTooLong. I think Windows just gives us a "could not create
process" without too many information.

Other than that I guess the performance tradeoff won't be that bad as
the first try would work out most of the time for almost everybody and
we'd actually avoid a couple of tests.

So catch everything and retry with the temporary file solution?

Stefan

Re: Commandline-Handling for external compilation

Posted by Dirk Weigenand <Di...@oracle.com>.
Nico Seessle wrote:

> I want to get back on this topic as it's still unsolved and I think it
> should be before Ant 1.2 (will people complain less "Ant will not work for
> me if I compile this many files").
>
> The problem:
> Different OS accept different max. length for the commandline passed to an
> external compiler. If Ant knows it's going over this limit it will use a
> temporary file and pass this file to the compiler via @tempfile. Currently
> this is only handled for Windows.
>
> Currently known limits are:
>
> Windows 32k (only 4k if a directory change is required and JDK < 1.3)
> Linux about 100k (including environment)
> AIX  about 20k (including environment)
> POSIX Standard seems to be 4k
>
> I can currently think of three ways solving this problem:
>
> 1. Always use a limit of 4k
> 2. Always use a limit of 4k except you know the OS you are currently running
> on has a higher limit and hard-code this in Javac (will require a change to
> the source for every 'new' OS)
> 3. Read the known limit's from a property file and check against these
> 4. Option 1 and allow people to override using a property if they know
> better
> 5. Option 2 for 'most often used OS' and allow people for their own OS if
> they know better
> 6. Don't change it (not really a 'solution')
>

7. Try to compile and check if there is an exception thrown that states that
the comandline was too long and then write the files to compile into a
temporary file and rerun the compile.

I.e.:

try {
  try {
    compile(args);
  } catch (CommandLineTooLongException cltle) {
    massage args into file and shorten args to contain only switches and the
@file argument
    rerun compile
  }
}catch (AnyOtherExceptionThatMightBeThrown aoetmbt) {
    throw new BuildException(aoetmbt);
}

I'm not sure what performance tradeoff i'm talking about here. But it would not
require any artificial limit imposed on the compile process. It would live with
the limit given by the surround OS.

Am i making sense?

Regards,
                Dirk