bug#12495: AC_CONFIG_HEADERS with

[Stefano Lattarini]

tags 12495 + moreinfo
thanks

Hello everybody, sorry for the late reply.

On 09/24/2012 11:20 AM, Hib Eris wrote:
> Hi,
> 
> On Mon, Sep 24, 2012 at 10:53 AM, Peter Johansson <address@hidden> wrote:
>>> I have attached an example setup.
>>> After running 'autoreconf -fi', I get a lib/Makefile.in with an rule
>>> to create $(srcdir)/config-public.h.in calling $(AUTOHEADER).
>>>
>>>
>> Yes, this looks like a bug IMVHO. The difference between your setup and mine
>> is that I only have one Makefile. But I just recently converted to
>> non-recursive makefiles, and haven't noticed this bug, which suggests this
>> is a recent regression (1.12???).
> 
> I get this with both automake 1.11.1 and current master. It seems to
> be there since this commit:
> 
> commit 262bb922f4ad55cebe9b7a7a6c6fa9ff67fb3ee9
> Author: Alexandre Duret-Lutz <address@hidden>
> Date:   Mon Jan 5 09:02:06 2004 +0000

Thanks for digging out all these details.  However, I still don't understand
why you consider the current Automake behaviour as a bug.  It seems to me it's
not in contrast with the documentation, which reads:

    AC_CONFIG_HEADERS:
      Automake will generate rules to rebuild these headers. Older versions
      of Automake required the use of AM_CONFIG_HEADER (see Macros); this is
      no longer the case.   As with AC_CONFIG_FILES (see Requirements), parts
      of the specification using shell variables will be ignored as far as
      cleaning, distributing, and rebuilding is concerned.

Also, I can't figure a situation where the current behaviour would be unhepful
rather then helpful.  But probably it's just me missing something here, since
I have basically no first-hand experience with complex use of AC_CONFIG_HEADERS.
So I'll wait for more feedback before deciding how to proceed in this matter.

Thanks,
  Stefano