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 <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).
[...]
> 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/)
