[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: automake 1.11.3 check-TESTS and command line length

From: Peter Rosin
Subject: Re: automake 1.11.3 check-TESTS and command line length
Date: Mon, 27 Feb 2012 12:15:22 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2

Stefano Lattarini skrev 2012-02-22 21:54:
> On 02/22/2012 09:22 PM, Bob Friesenhahn wrote:
>> On Wed, 22 Feb 2012, Stefano Lattarini wrote:
>>> I don't understand how that patch could actually work ...  If there are
>>> too many tests in $(TESTS), there will be too many logs in $(TEST_LOGS),
>>> and since the recipe for $(TEST_SUITE_LOG) contents the expansion of
>>> $(TEST_LOGS), the command line length limit for "/bin/sh -c" will be
>>> exceeded anyway ...
>> I don't claim to understand how the patch functions other than
>> that it seems to delegate responsibility to a subordinate make.
> Basically, it was trying (and succeeding!) to pass the list of tests
> to the subordinate make on the stdin rather than on the command line,
> to avoid hitting any command-line length limit.  It was a pretty
> simple and clever hack.  The problem is that the list of tests will
> still *have* to be finally expanded in the recipe that creates
> 'test-suite.log', at which point all our attempt to avoid exceeding
> command line length limits in recursive make invocations becomes
> useless, no matter how clever of fast.
>>>> A GNU make dependency would be a real problem.  A dependency on a
>>>> properly-working standard make would not be such a problem.
>>> Is the test suite actually failing due to "exceeded command line length"
>>> on any system different from Cygwin or MinGW?  If not, I don't see how a
>>> GNU make dependency would be a problem (if not for the fact that it
>>> uglifies the already hideous patch even more).
>> I have only observed it on MinGW/MSYS but that does not mean it will
>> not appear on some Unix OS with unusually short command line length.
> True; but I say, let's cross that bridge when come at it :-)
>> A GNU make dependency would be a problem if it depends on GNU make
>> for other systems.
> This wouldn't be the case: the change causes the GNU make specific code
> to be used only if ./configure determines that the make program in use
> is GNU make.  Otherwise, the old implementation would still been used.
> So, no regression for the non-GNU makes (even if the pre-existing
> command-line length isse wouldn't have been fixed for them).
>> On MinGW, /bin/sh throws an error but I don't recall that it provides
>> a useful diagnostic like "exceeded command line length".  It seemed
>> to me that the argument list was truncated.
>>>> I have not run into any problems when using Ralf's patch, but it apparently
>>>> does not address all issues so Ralf backed it out.
>>> In fact, it fundamentally fails to address the issues -- that's why Ralf
>>> backed it out.
>> All I know is that with the patch I did not experience a failure on any
>> system.
> That's weird; clearly I'm missing something in the big picture here ...
> Maybe Peter can chime in with his MinGW expertise and save the day? ;-)

I *think* the environment and the command line shares space (approx 64kB,
I repeat *think* here, I don't know the details off the top of my head, Cygwin
isn't affected since it uses the cygwin DLL to communicate this stuff between
cygwin processes using normal ipc mechanisms).  If I'm right, reducing the
command line length for a process might sufficiently elevate the limit, even
if it isn't eliminated.

I'm no expert in that area...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]