bug#10437: parallel-tests: `recheck' recipe can cause sed to be invoked with too long input lines (was: Re: bug#10427: coreutils-8.14.116-1e18d: testsuite failures on NetBSD 5.1)

[Stefano Lattarini]

[adding bug-automake in CC:]

Reference: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10427#8>

Hi Paul, thanks for the report and diagnosis.

On 01/05/2012 10:00 AM, Paul Eggert wrote:
> The latest coreutils snapshot fail to build
> 
>> On 01/03/2012 06:10 PM, Jim Meyering wrote:
>>> FYI, here's a snapshot of what will soon be coreutils-8.15,
>>> expected on Thursday or Friday.
>>>
>>> coreutils snapshot:
>>>   http://meyering.net/cu/coreutils-ss.tar.xz      5.2 MB
>>>   http://meyering.net/cu/coreutils-ss.tar.xz.sig
>>>   http://meyering.net/cu/coreutils-8.14.116-1e18d.tar.xz
> 
> This snapshot doesn't build on Solaris 8 (sparc) with native tools,
> for a couple of reasons.  I don't expect Solaris 8 is an active
> porting target any more, but these problems could well happen on
> active targets.
>
I agree.

> Second, there's code like this in tests/Makefile.in:
> 
>       @list='$(TEST_LOGS)'; \
>       list=`for i in $$list; do \
>         test .log = $$i || echo $$i; \
>       done | tr '\012\015' '  '`; \
>       list=`echo "$$list" | sed 's/ *$$//'`; \
> 
> This generates a long line and sends it to 'sed',
> which complains "Output line too long." and outputs nothing.
>
And if I'm not mistaken, sed is allowed such a behaviour by POSIX, so this
is a portability problem in automake.

> This code is also generated by Automake.  How about changing Automake
> to generate something like this instead?
> 
>       @test_logs='$(TEST_LOGS)'; \
>       list=; \
>       for i in $$test_logs; do \
>         test .log = "$$i" || list="$$list $$i"; \
>       done; \
> 
> This avoids the business with echo and tr and ` sed and
> avoids the sed limitation with long lines.
>
Good idea.  I will followed your idea (with some tweaks).
Patch coming up soon.

> Automake does this latter sort of thing in about 4 places,
>
Which "sort of thing" exactly?  I could find only one place which suffers
of the problem you've pointed out, i.e., the `recheck recheck-html' rules
in lib/am/check.am.  Am I missing something?

> and I figure it's done that way for a reason, but I don't
> know what the reason is.
> 
The comments in lib/am/check.am should be explicative enough.  if not,
that's a (minor) bug, so feel free to report it!

Thanks,
  Stefano