bug#12495: AC_CONFIG_HEADERS with

[Nick Bowler]

On 2012-09-27 10:38 +0200, Stefano Lattarini wrote:
> On 09/24/2012 11:20 AM, Hib Eris wrote:
> > 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).
[...]
> 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.

I /think/ the situation being described is demonstrated by the
following.  That being said, the behaviour doesn't seem to be harmful;
just useless.

% cat >configure.ac <<'EOF'
AC_INIT([test], [0])
AC_CONFIG_HEADERS([config.h foo/fooconfig.h])

AM_INIT_AUTOMAKE([foreign])
AC_CONFIG_FILES([Makefile foo/Makefile])
AC_OUTPUT
EOF

% mkdir foo
% touch Makefile.am foo/Makefile.am foo/fooconfig.h.in
% autoreconf -is

% ./configure
% touch configure.ac
% (cd foo && make fooconfig.h.in)

Since Automake outputs a rule[1] in foo/Makefile.in to update
fooconfig.h.in, make tries to do so (by running autoheader).  But
autoheader doesn't actually update fooconfig.h.in as fooconfig.h is
not the first header listed in AC_CONFIG_HEADERS.  So executing this
rule is pointless as its commands will never modify the target.

Fortunately in this case, the rule to update fooconfig.h.in also
contains a simple touch command, so it does actually update the
target timestamp.  But it would have been better to simply do
nothing since the target is not actually out of date.

[1] For reference, the rule output by automake is as follows:

$(srcdir)/fooconfig.h.in:  $(am__configure_deps) 
        ($(am__cd) $(top_srcdir) && $(AUTOHEADER))
        rm -f stamp-h2
        touch $@

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)