[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#10427: parallel-tests: `recheck' recipe can cause sed to be invoked
bug#10427: 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)
Thu, 05 Jan 2012 15:07:06 +0100
[adding bug-automake in CC:]
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
> 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.
> 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!