]> git.ipfire.org Git - thirdparty/automake.git/commit
[ng] memoize: expose a serious bug (affecting GNU make < 3.83)
authorStefano Lattarini <stefano.lattarini@gmail.com>
Tue, 15 May 2012 09:18:17 +0000 (11:18 +0200)
committerStefano Lattarini <stefano.lattarini@gmail.com>
Tue, 15 May 2012 09:20:09 +0000 (11:20 +0200)
commit34a7d424ae60124f17dc50a18196f7b4876802fb
tree2cbf24d3da68c265d9b6e69bff01182a5eb678ec
parentd55204f061739ec758d0071f6a76b512adf0512b
[ng] memoize: expose a serious bug (affecting GNU make < 3.83)

This is a follow-up to commit v1.12-217-gd55204f of 2012-05-12,
"[ng] vars: implement memoization of make variables (new 'am__memoize'
func)".

So, apparently, all our workarounds aimed at avoiding the subtle GNU
make bug affecting variable memoization:

  <http://lists.gnu.org/archive/html/bug-make/2012-05/msg00013.html>
  <https://savannah.gnu.org/patch/?7534>

have not been enough :-(

When trying to use 'am__memoize' in a non-trivial setup (to optimize
the new form of the parallel-tests harness implemented by the series
http://lists.gnu.org/archive/html/automake-ng/2012-05/msg00015.html),
we stumbled upon that bug again.  At this point, it's quite clear that
there is no safe way to safely avoid it, so we'll have to find a way
to enable memoization (that is just an optimization) only with GNU
make >= 3.83 (once that is out).

Here, we just enhance our testsuite to expose the (re)discovered
issue.

* t/memoize.tap: Enhance.  The new check fails with GNU make <= 3.82,
and passes with the development version of GNU make (which should
become GNU make 3.83 eventually).

Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
t/memoize.tap