bug#12495: AC_CONFIG_HEADERS with

[Hib Eris]

Hi all,

On Thu, Sep 27, 2012 at 4:20 PM, Nick Bowler <address@hidden> wrote:
> 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.

IMHO the statement that automake will generate rules to rebuild these
headers is suggesting that automake does more than it actually can.
Automake does not really know how the headers should be rebuild, thus
it assumes it can do so by running autoheader which as far as I
understand always creates only a config.h.in file.

>> 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.

You are correct. This is what I described.

> 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.

I think it would even be better if the target had not existed in the
first place.

>From reading the source of lib/am/remake-hdr.am I think it was also
the intention of automake to not generate this target for all headers
except the first one, but I think this functionality was accidentally
lost with
commit 262bb922f4ad55cebe9b7a7a6c6fa9ff67fb3ee9

On the matter of harmfullness/helpfullness/pointlessness of this
behaviour, I do not think current behaviour does any harm. For me it
just causes 6 ugly lines of output that I previously did not
understood when I run 'make' and which triggered me to look into it to
clean up my build log.

So this certainly is no show stopper, but I think it would be nice
nevertheless to have it fixed.

Cheers,

Hib