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 <troj...@gmail.com> 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 <a...@gnu.org>
> 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
