Fix for _AC_AM_CONFIG_HEADER_HOOK (CONFIG_HEADER stamp file creation)bug

[Sander Niemeijer]

This replacement for the _AC_AM_CONFIG_HEADER_HOOK macro (located in m4/init.m4) fixes an incorrect naming issue of stamp-h* files when only specific headers are recreated through config.status.

The problem can be reproduced by creating a configure.ac file containing:
---
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_HEADERS([someotherfile.h])
---
When configure first creates the .h files from the .h.in files the proper stamp-h1 and stamp-h2 files are created. Now modify someotherfile.h.in and call 'make' again. This results in a call to '$(SHELL) ./config.status someotherfile.h' to recreate someotherfile.h. However, config.status now incorrectly creates a stamp-h1 file instead of stamp-h2 file.

The following proposed replacement for _AC_AM_CONFIG_HEADER_HOOK fixes this issue:
---
AC_DEFUN([_AC_AM_CONFIG_HEADER_HOOK],
[_am_stamp_count=0
_am_local_stamp_count=0
for ac_stamped_file in $config_headers : ; do
_am_local_stamp_count=`expr ${_am_local_stamp_count} + 1`
test $ac_stamped_file = $1 && _am_stamp_count=$_am_local_stamp_count
done
echo "timestamp for $1" >`AS_DIRNAME([$1])`/stamp-h[]$_am_stamp_count])
---

P.S. A better replacement would be to have the $config_headers list passed along as variable to the _AC_AM_HEADER_HOOK macro. This would keep the macro independent of any outside variables. But on the other hand this would mean that the every invocation of this macro should be changed and I don't really know whether that could brake any other packages (like e.g. autoconf) that might depend on this macro. Anybody any idea about that?

Regards,
Sander Niemeijer