Subject: Re: bug#13477: automake 1.13 breaks when TESTS variable contains GNU make macros like $(sort ...)
From: Stefano Lattarini <[email-masked]>
To: "Richard W.M. Jones" <[email-masked]>
Cc: [email-masked]
Date: Thu, 17 Jan 2013 21:56:25 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

On 01/17/2013 08:19 PM, Richard W.M. Jones wrote:
> On Thu, Jan 17, 2013 at 07:29:29PM +0100, Stefano Lattarini wrote:
>> On 01/17/2013 01:36 PM, Richard W.M. Jones wrote:
>>> I have a project that has a TESTS variable like this ('test_progs' is
>>> defined elsewhere):
>>>
>>> TESTS = run-bindtests \
>>> 	$(sort \
>>> 		$(patsubst %,%.bc,$(test_progs)) \
>>> 		$(patsubst %,%.opt,$(test_progs)))
>>>
>>> This breaks with automake 1.13.1.  'make' gives unterminated variable
>>> errors.  It is fairly obvious why when you look at the generated code:
>>>
>>> run-bindtests.log: run-bindtests
>>> 		   @p='run-bindtests'; \
>>> 		   b='run-bindtests'; \
>>>         $(am__check_pre) $(LOG_DRIVER) --test-name "$$f" \
>>>         --log-file $$b.log --trs-file $$b.trs \
>>>         $(am__common_driver_flags) $(AM_LOG_DRIVER_FLAGS) $(LOG_DRIVER_FLAGS) -\
>>> - $(LOG_COMPILE) \
>>>         "$$tst" $(AM_TESTS_FD_REDIRECT)
>>> $(sort.log: $(sort
>>>         @p='$(sort'; \
>>>         b='$(sort'; \
>>>         $(am__check_pre) $(LOG_DRIVER) --test-name "$$f" \
>>>         --log-file $$b.log --trs-file $$b.trs \
>>>         $(am__common_driver_flags) $(AM_LOG_DRIVER_FLAGS) $(LOG_DRIVER_FLAGS) -\
>>> - $(LOG_COMPILE) \
>>>         "$$tst" $(AM_TESTS_FD_REDIRECT)
>>> $(patsubst.log: $(patsubst
>>>         @p='$(patsubst'; \
>>>         b='$(patsubst'; \
>>> 	$(am__check_pre) $(LOG_DRIVER) --test-name "$$f" \
>>>         --log-file $$b.log --trs-file $$b.trs \
>>>         $(am__common_driver_flags) $(AM_LOG_DRIVER_FLAGS) $(LOG_DRIVER_FLAGS) -\
>>> - $(LOG_COMPILE) \
>>>         "$$tst" $(AM_TESTS_FD_REDIRECT)
>>> %,%.bc,$(test_progs)).log: %,%.bc,$(test_progs))
>>>
>>> This used to work fine in automake <= 1.12.  I also tried jamming the
>>> whole thing into a single line, but that didn't help.
>>>
>> Does the thing work again if you use the 'serial-tests' option (which was the
>> default before automake 1.13)?
> 
> Yes, specifying serial-tests does appear to have fixed this.
> 
OK, as I suspected.  The problem is that the use of GNU make built-in
in TESTS was *never* supported by the parallel harness, unfortunately :-(

Since that is nothing new, I'm closing this bug report.

Thanks,
  Stefano