GNU bug report logs - #12495
AC_CONFIG_HEADERS with

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12495 in the body.
You can then email your comments to 12495 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Hib Eris <hib <at> hiberis.nl>
To: bug-automake <at> gnu.org
Subject: AC_CONFIG_HEADERS with
Date: Sun, 23 Sep 2012 17:57:39 +0200

[Message part 1 (text/plain, inline)]

Hi,

With AC_CONFIG_HEADERS(config.h subdir/myconfig.h) in configure.ac,
automake generates a target to build config.h.in with autoheader in
Makefile.in (as expected),
but it also generates a target in subdir/Makefile.in to build
subdir/myconfig.h.in which also runs autoheader.
This last target does not create subdir/myconfig.h as autoheader only
generates config.h, so this seems wrong.

I could not find much in the documentation of automake about what is
supposed to happen, but in the
source of  lib/am/remake-hdr.am I read:

## Only the first file of AC_CONFIG_HEADERS is assumed to be generated
## by autoheader.

So I understand that it is not the intention to have more then one
header file to trigger autoheader.
This only seems to happen when the second header file is in a subdir. With
AC_CONFIG_HEADERS(config.h myconfig.h) things work as expected, so I
guess this might be a bug that gets triggered only with header files
in subdirs.

I have attached a patch that fixes this problem for me.

Kind regards,

Hib Eris

[0001-Do-not-call-autoheader-with-header-files-in-subdirs.patch (application/octet-stream, attachment)]

Message #8 received at 12495 <at> debbugs.gnu.org (full text, mbox):

From: Peter Johansson <trojkan <at> gmail.com>
To: Hib Eris <hib <at> hiberis.nl>
Cc: 12495 <at> debbugs.gnu.org
Subject: Re: bug#12495: AC_CONFIG_HEADERS with
Date: Mon, 24 Sep 2012 16:29:04 +1000

On 09/24/2012 01:57 AM, Hib Eris wrote:
> Hi,
>
> With AC_CONFIG_HEADERS(config.h subdir/myconfig.h) in configure.ac,
> automake generates a target to build config.h.in with autoheader in
> Makefile.in (as expected),
> but it also generates a target in subdir/Makefile.in to build
> subdir/myconfig.h.in which also runs autoheader.
> This last target does not create subdir/myconfig.h as autoheader only
> generates config.h, so this seems wrong.
Hi Hib,

I have the setup you describe, and I have not encountered the problem 
you describe.

I have AC_CONFIG_HEADERS([config.h lib/config_public.h])

and there is no rule to create 'lib/config_public.h.in'. Am I missing 
something?

Cheers,
Peter

Message #11 received at 12495 <at> debbugs.gnu.org (full text, mbox):

From: Hib Eris <hib <at> hiberis.nl>
To: Peter Johansson <trojkan <at> gmail.com>
Cc: 12495 <at> debbugs.gnu.org
Subject: Re: bug#12495: AC_CONFIG_HEADERS with
Date: Mon, 24 Sep 2012 10:18:05 +0200

[Message part 1 (text/plain, inline)]

Hi Peter,

Thanks for looking into this.

On Mon, Sep 24, 2012 at 8:29 AM, Peter Johansson <trojkan <at> gmail.com> wrote:
>
> I have the setup you describe, and I have not encountered the problem you
> describe.
>
> I have AC_CONFIG_HEADERS([config.h lib/config_public.h])
>
> and there is no rule to create 'lib/config_public.h.in'. Am I missing
> something?

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

Hib Eris

[example.tgz (application/x-gzip, attachment)]

Message #14 received at 12495 <at> debbugs.gnu.org (full text, mbox):

From: Peter Johansson <trojkan <at> gmail.com>
To: Hib Eris <hib <at> hiberis.nl>
Cc: 12495 <at> debbugs.gnu.org
Subject: Re: bug#12495: AC_CONFIG_HEADERS with
Date: Mon, 24 Sep 2012 18:53:38 +1000

On 9/24/12 6:18 PM, Hib Eris wrote:
> Hi Peter,
>
> Thanks for looking into this.
>
> On Mon, Sep 24, 2012 at 8:29 AM, Peter Johansson<trojkan <at> gmail.com>  wrote:
>> I have the setup you describe, and I have not encountered the problem you
>> describe.
>>
>> I have AC_CONFIG_HEADERS([config.h lib/config_public.h])
>>
>> and there is no rule to create 'lib/config_public.h.in'. Am I missing
>> something?
> 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???).

Cheers,
Peter

-- 
Peter Johansson

Message #17 received at 12495 <at> debbugs.gnu.org (full text, mbox):

From: Hib Eris <hib <at> hiberis.nl>
To: Peter Johansson <trojkan <at> gmail.com>
Cc: 12495 <at> debbugs.gnu.org
Subject: Re: bug#12495: AC_CONFIG_HEADERS with
Date: Mon, 24 Sep 2012 11:20:33 +0200

Hi,

On Mon, Sep 24, 2012 at 10:53 AM, Peter Johansson <trojkan <at> 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 <adl <at> gnu.org>
Date:   Mon Jan 5 09:02:06 2004 +0000

Cheers,
Hib

Message #20 received at 12495 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Hib Eris <hib <at> hiberis.nl>
Cc: Peter Johansson <trojkan <at> gmail.com>, 12495 <at> debbugs.gnu.org
Subject: Re: bug#12495: AC_CONFIG_HEADERS with
Date: Thu, 27 Sep 2012 10:38:09 +0200

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 <trojkan <at> 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 <adl <at> 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

Message #25 received at 12495 <at> debbugs.gnu.org (full text, mbox):

From: Nick Bowler <nbowler <at> elliptictech.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Peter Johansson <trojkan <at> gmail.com>, Hib Eris <hib <at> hiberis.nl>,
	12495 <at> debbugs.gnu.org
Subject: Re: bug#12495: AC_CONFIG_HEADERS with
Date: Thu, 27 Sep 2012 10:20:03 -0400

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 <trojkan <at> 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/)

Message #28 received at 12495 <at> debbugs.gnu.org (full text, mbox):

From: Hib Eris <hib <at> hiberis.nl>
To: Nick Bowler <nbowler <at> elliptictech.com>
Cc: Peter Johansson <trojkan <at> gmail.com>,
	Stefano Lattarini <stefano.lattarini <at> gmail.com>, 12495 <at> debbugs.gnu.org
Subject: Re: bug#12495: AC_CONFIG_HEADERS with
Date: Thu, 27 Sep 2012 21:53:27 +0200

Hi all,

On Thu, Sep 27, 2012 at 4:20 PM, Nick Bowler <nbowler <at> elliptictech.com> 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 <trojkan <at> 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.

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

Message #31 received at 12495 <at> debbugs.gnu.org (full text, mbox):

From: Nick Bowler <nbowler <at> elliptictech.com>
To: Hib Eris <hib <at> hiberis.nl>
Cc: Peter Johansson <trojkan <at> gmail.com>,
	Stefano Lattarini <stefano.lattarini <at> gmail.com>, 12495 <at> debbugs.gnu.org
Subject: Re: bug#12495: AC_CONFIG_HEADERS with
Date: Thu, 27 Sep 2012 16:13:10 -0400

On 2012-09-27 21:53 +0200, Hib Eris wrote:
> On Thu, Sep 27, 2012 at 4:20 PM, Nick Bowler <nbowler <at> elliptictech.com> wrote:
> > 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.

Indeed; that is what I was trying to say (perhaps not very well).  Not
having the rule at all should achieve the result of doing nothing (the
other option being an empty rule, which would be pretty silly.)

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

Message #34 received at 12495 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Hib Eris <hib <at> hiberis.nl>
Cc: Nick Bowler <nbowler <at> elliptictech.com>, Peter Johansson <trojkan <at> gmail.com>,
	12495 <at> debbugs.gnu.org
Subject: Re: bug#12495: AC_CONFIG_HEADERS with
Date: Fri, 28 Sep 2012 09:40:19 +0200

tags 12495 - moreinfo
thanks

On 09/27/2012 09:53 PM, Hib Eris wrote:
> Hi all,
> 
> On 09/24/2012 11:20 AM, Hib Eris wrote:
>> On 2012-09-27 10:38 +0200, Stefano Lattarini wrote:
>
>> [...]
>>> 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.
>
And the autoconf manual indeed reads:

    The autoheader program ... searches for the *first* invocation of
    AC_CONFIG_HEADERS in configure sources to determine the name of the
    template.  If the first call of AC_CONFIG_HEADERS specifies more
    than one input file name, autoheader uses the first one.

Now I understand your objections, and I agree that the current Automake
behaviour is a bug (albeit a minor one).  I'll commit a fix in the next
days.

Thanks,
  Stefanno

Message #39 received at 12495 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Hib Eris <hib <at> hiberis.nl>
Cc: Nick Bowler <nbowler <at> elliptictech.com>, Peter Johansson <trojkan <at> gmail.com>,
	"automake-patches <at> gnu.org" <automake-patches <at> gnu.org>,
	12495 <at> debbugs.gnu.org
Subject: Re: bug#12495: AC_CONFIG_HEADERS with
Date: Sat, 29 Sep 2012 20:18:11 +0200

tags 12495 + patch
thanks

On 09/28/2012 09:40 AM, Stefano Lattarini wrote:
>
> Now I understand your objections, and I agree that the current Automake
> behaviour is a bug (albeit a minor one).  I'll commit a fix in the next
> days.
>
Here is the patch finally.  I will commit it in a couple of days if there
are no objections.  As usual, comments are welcome.

Thanks,
  Stefano

---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ----

From 21bcf5bf85908ac98ff131467f78d584579870ea Mon Sep 17 00:00:00 2001
Message-Id: <21bcf5bf85908ac98ff131467f78d584579870ea.1348942478.git.stefano.lattarini <at> gmail.com>
From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Date: Fri, 28 Sep 2012 21:27:41 +0200
Subject: [PATCH] config headers: don't emit rules for headers not generated
 by autoheader

This change fixed automake bug#12495.

Even if an AC_CONFIG_HEADERS invocation is passed a list of several files
as the first argument, only the first one of those file is considered by
autoheader for automatic generation of the corresponding '.in' template.
This is done on purpose, and is clearly documented in the Autoconf manual,
which (as of the 2.69 version) reads something like this:

    The autoheader program searches for the first invocation of
    AC_CONFIG_HEADERS in configure sources to determine the name of
    the template.  If the first call of AC_CONFIG_HEADERS specifies
    more than one input file name, autoheader uses the first one.

That is, an invocation like:

    AC_CONFIG_HEADERS([config.h config2.h])

should cause autoheader to generate only a 'config.h.in' template,
and not also a 'config2.h.in' one.

Accordingly, automake, when tracing AC_CONFIG_HEADERS, should generate
remake rules only for the template associated to the first input file
name passed to that macro.  In some situations, however, automake failed
to properly limit itself in this way; for example, with an input like:

    AC_CONFIG_HEADERS([config.h sub/foo.h])

in configure.ac, and with the 'sub' directory listed in the SUBDIRS
variable of the top-level Makefile, automake would erroneously generate
in 'sub/Makefile.in' a rule to remake the 'foo.h.in' template by
invoking autoheader.

This issue was likely introduced in commit 'Release-1-8-23-g262bb92'
of 2004-01-05.

* NEWS: Update.
* doc/automake.texi (Optional): Improve wording in the description of
hat rules automake generates in response to an 'AC_CONFIG_HEADERS'
invocation.
* lib/am/remake-hdr.am: Only emit autoheader-invoking remake rules for
the %CONFIG_HIN% template if that corresponds to the first argument of
AC_CONFIG_HEADERS, as explaned above.  Do so using the automake-time
conditional %?FIRST-HDR%, that is properly passed ...
* automake.in (handle_configure): ... from a 'file_contents' invocation
in here.
* t/autohdr-subdir-pr12495.sh: New test.
* t/list-of-tests.mk: Add it.
* THANKS: Update.

Helped-by: Hib Eris <hib <at> hiberis.nl>
Signed-off-by: Stefano Lattarini <stefano.lattarini <at> gmail.com>
---
 NEWS                        | 14 +++++++-
 THANKS                      |  1 +
 automake.in                 |  1 +
 doc/automake.texi           |  8 +++--
 lib/am/remake-hdr.am        |  4 +--
 t/autohdr-subdir-pr12495.sh | 80 +++++++++++++++++++++++++++++++++++++++++++++
 t/list-of-tests.mk          |  1 +
 7 files changed, 103 insertions(+), 6 deletions(-)
 create mode 100755 t/autohdr-subdir-pr12495.sh

diff --git a/NEWS b/NEWS
index d67407f..aaa3ad3 100644
--- a/NEWS
+++ b/NEWS
@@ -1,4 +1,4 @@
-New in 1.12.4:
+New in 1.12.5:

 * WARNING: Future backward-incompatibilities!

@@ -61,6 +61,18 @@ New in 1.12.4:
     giving more useful warnings than a bare "command not found" from a
     make recipe would.

+Bugs fixed in 1.12.5:
+
+* Long-standing bugs:
+
+  - Automake no longer generates spurious remake rules invoking autoheader
+    to regenerate the template corresponding to header files specified after
+    the first one in AC_CONFIG_HEADERS (automake bug#12495).
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+New in 1.12.4:
+
 * Warnings and deprecations:

   - Warnings in the 'obsolete' category are enabled by default both in
diff --git a/THANKS b/THANKS
index ca95db8..88f539c 100644
--- a/THANKS
+++ b/THANKS
@@ -143,6 +143,7 @@ Harald Dunkel                   harald <at> CoWare.com
 Harlan Stenn                    Harlan.Stenn <at> pfcs.com
 He Li                           tippa000 <at> yahoo.com
 Henrik Frystyk Nielsen          frystyk <at> w3.org
+Hib Eris                        hib <at> hiberis.nl
 Ian Lance Taylor                ian <at> cygnus.com
 Ignacy Gawedzki                 i <at> lri.fr
 Илья Н. Голубев                 gin <at> mo.msk.ru
diff --git a/automake.in b/automake.in
index 8c8b127..944b985 100644
--- a/automake.in
+++ b/automake.in
@@ -4225,6 +4225,7 @@ sub handle_configure ($$$@)
 	    file_contents ('remake-hdr',
 			   new Automake::Location,
 			   FILES            => "@files",
+			   'FIRST-HDR'      => ($hdr_index == 1),
 			   CONFIG_H         => $cn_sans_dir,
 			   CONFIG_HIN       => $ins[0],
 			   CONFIG_H_DEPS    => "@ins",
diff --git a/doc/automake.texi b/doc/automake.texi
index 0838822..914c1e8 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -2979,9 +2979,11 @@ Automake will require the sources file declared with
 macro.

 @item AC_CONFIG_HEADERS
-Automake will generate rules to rebuild these headers.  Older versions
-of Automake required the use of @code{AM_CONFIG_HEADER}
-(@pxref{Macros}); this is no longer the case.
+Automake will generate rules to rebuild these headers from the
+corresponding templates (usually, the template for a @file{foo.h}
+header being @file{foo.h.in}).  Older versions of Automake required
+the use of @code{AM_CONFIG_HEADER} (@pxref{Macros}); this is no
+longer the case.

 As with @code{AC_CONFIG_FILES} (@pxref{Requirements}), parts of the
 specification using shell variables will be ignored as far as
diff --git a/lib/am/remake-hdr.am b/lib/am/remake-hdr.am
index f61400a..3c7e346 100644
--- a/lib/am/remake-hdr.am
+++ b/lib/am/remake-hdr.am
@@ -30,7 +30,7 @@

 ## Only the first file of AC_CONFIG_HEADERS is assumed to be generated
 ## by autoheader.
-if %?FIRST%
+if %?FIRST-HDR%
 %CONFIG_HIN%: %MAINTAINER-MODE% $(am__configure_deps) %FILES%
 ## Cater to parallel BSD make.
 	($(am__cd) $(top_srcdir) && $(AUTOHEADER))
@@ -71,4 +71,4 @@ if %?FIRST%
 ## by config.status, there is no reason to make things complex for
 ## config.hin.
 	touch $@
-endif %?FIRST%
+endif %?FIRST-HDR%
diff --git a/t/autohdr-subdir-pr12495.sh b/t/autohdr-subdir-pr12495.sh
new file mode 100755
index 0000000..77d2522
--- /dev/null
+++ b/t/autohdr-subdir-pr12495.sh
@@ -0,0 +1,80 @@
+#! /bin/sh
+# Copyright (C) 2012 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# Related to automake bug#12495: Automake shouldn't generate useless
+# remake rules for AC_CONFIG_HEADERS arguments after the first one,
+# not even when subdirs are involved.
+
+. ./defs || exit 1
+
+cat >> configure.ac << 'END'
+AC_CONFIG_HEADERS([a.h b.h sub/c.h])
+AC_CONFIG_FILES([sub/Makefile])
+AC_OUTPUT
+END
+
+mkdir sub
+echo SUBDIRS = sub > Makefile.am
+: > sub/Makefile.am
+
+$ACLOCAL
+$AUTOCONF
+$AUTOHEADER
+# Even if an AC_CONFIG_HEADERS invocation is passed several files in
+# the first argument, only the first one is considered by autoheader
+# for automatic generation.  Otherwise, the present test case would
+test -f a.h.in && test ! -f c.h.in && test ! -f sub/c.h.in \
+  || fatal_ "unexpected autoheader behavior with multiple" \
+            "AC_CONFIG_HEADERS arguments"
+# Automake should require the missing headers though.
+AUTOMAKE_fails -Wno-error -Wnone
+grep "^configure\.ac:4:.* required file 'b.h.in' not found" stderr
+grep "^configure\.ac:4:.* required file 'sub/c.h.in' not found" stderr
+: > b.h.in
+: > sub/c.h.in
+$AUTOMAKE
+
+./configure
+
+# Automake should regenerate this.
+grep '^$(srcdir)/a\.h\.in:' Makefile.in
+# But not these.
+grep '[bc]\.h\.in.*:' Makefile.in sub/Makefile.in && exit 1
+
+test -f a.h && test -f b.h && test -f sub/c.h \
+  || fatal_ "unexpected ./configure behavior with multiple" \
+            "AC_CONFIG_HEADERS arguments"
+
+rm -f a.h.in a.h
+$MAKE
+test -f a.h.in
+test -f a.h
+
+ocwd=$(pwd)
+for x in b c; do
+  test $x = b || cd sub
+  rm -f $x.h.in
+  $MAKE $x.h.in 2>stderr && { cat stderr >&2; exit 1; }
+  cat stderr >&2
+  test ! -f $x.h.in
+  if using_gmake; then
+    grep "No rule to make target [\`\"']$x\.h\.in[\`\"']" stderr
+  fi
+  : > $x.h.in
+  cd "$ocwd" || fatal_ "cannot chdir back"
+done
+
+:
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index 6effe77..b3ff6b2 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -158,6 +158,7 @@ t/autohdr.sh \
 t/autohdr2.sh \
 t/autohdr3.sh \
 t/autohdr4.sh \
+t/autohdr-subdir-pr12495.sh \
 t/autohdrdry.sh \
 t/automake-cmdline.tap \
 t/auxdir.sh \
-- 
1.7.12.317.g1c54b74

Message #44 received at 12495 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Hib Eris <hib <at> hiberis.nl>
Cc: Nick Bowler <nbowler <at> elliptictech.com>, Peter Johansson <trojkan <at> gmail.com>,
	"automake-patches <at> gnu.org" <automake-patches <at> gnu.org>,
	12495 <at> debbugs.gnu.org
Subject: Re: bug#12495: AC_CONFIG_HEADERS with
Date: Tue, 02 Oct 2012 16:43:20 +0200

tags 12495 + patch
close 12495
thanks

On 09/29/2012 08:18 PM, Stefano Lattarini wrote:
> Here is the patch finally.  I will commit it in a couple of days if there
> are no objections.  As usual, comments are welcome.
>
> ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ----
> 
> Subject: [PATCH] config headers: don't emit rules for headers not generated by autoheader
> 
> This change fixed automake bug#12495.
> 
> Even if an AC_CONFIG_HEADERS invocation is passed a list of several files
> as the first argument, only the first one of those file is considered by
> autoheader for automatic generation of the corresponding '.in' template.
> This is done on purpose, and is clearly documented in the Autoconf manual,
> which (as of the 2.69 version) reads something like this:
> 
>     The autoheader program searches for the first invocation of
>     AC_CONFIG_HEADERS in configure sources to determine the name of
>     the template.  If the first call of AC_CONFIG_HEADERS specifies
>     more than one input file name, autoheader uses the first one.
> 
> That is, an invocation like:
> 
>     AC_CONFIG_HEADERS([config.h config2.h])
> 
> should cause autoheader to generate only a 'config.h.in' template,
> and not also a 'config2.h.in' one.
> 
> Accordingly, automake, when tracing AC_CONFIG_HEADERS, should generate
> remake rules only for the template associated to the first input file
> name passed to that macro.  In some situations, however, automake failed
> to properly limit itself in this way; for example, with an input like:
> 
>     AC_CONFIG_HEADERS([config.h sub/foo.h])
> 
> in configure.ac, and with the 'sub' directory listed in the SUBDIRS
> variable of the top-level Makefile, automake would erroneously generate
> in 'sub/Makefile.in' a rule to remake the 'foo.h.in' template by
> invoking autoheader.
> 
> This issue was likely introduced in commit 'Release-1-8-23-g262bb92'
> of 2004-01-05.
> 
> * NEWS: Update.
> * doc/automake.texi (Optional): Improve wording in the description of
> hat rules automake generates in response to an 'AC_CONFIG_HEADERS'
> invocation.
> * lib/am/remake-hdr.am: Only emit autoheader-invoking remake rules for
> the %CONFIG_HIN% template if that corresponds to the first argument of
> AC_CONFIG_HEADERS, as explaned above.  Do so using the automake-time
> conditional %?FIRST-HDR%, that is properly passed ...
> * automake.in (handle_configure): ... from a 'file_contents' invocation
> in here.
> * t/autohdr-subdir-pr12495.sh: New test.
> * t/list-of-tests.mk: Add it.
> * THANKS: Update.
> 
Pushed now.  I'm thus closing this ticket.

Thanks,
  Stefano

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.