GNU bug report logs - #7648
ylwrap appears not to support bison's lalr1.cc skeleton

Previous Next

Package: automake;

Reported by: James Bostock <james.bostock <at> gmail.com>

Date: Wed, 15 Dec 2010 18:45:02 UTC

Severity: normal

Done: Stefano Lattarini <stefano.lattarini <at> gmail.com>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to owner <at> debbugs.gnu.org, bug-automake <at> gnu.org:
bug#7648; Package automake. (Wed, 15 Dec 2010 18:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to James Bostock <james.bostock <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-automake <at> gnu.org. (Wed, 15 Dec 2010 18:45:03 GMT) Full text and rfc822 format available.

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

From: James Bostock <james.bostock <at> gmail.com>
To: bug-automake <at> gnu.org
Subject: ylwrap appears not to support bison's lalr1.cc skeleton
Date: Wed, 15 Dec 2010 19:27:19 +0100
[Message part 1 (text/plain, inline)]
Hi,

Automake version 1.11.1
Autoconf version 2.67
Bison versions 1.875 and 2.4.1

If bison is directed to use the lalr1.cc skeleton file then although
ylwrap renames the files generated by bison, it does not update the
generated parser source code to #include the renamed header file.
Attached is a test script that illustrates the problem.

In more detail, the generated parser tries to #include the file "y.tab.h":

 48
 49 #include "y.tab.h"
 50

But y.tab.h has been renamed to zardoz.h by ylwrap, causing compilation to fail:

$ make
g++ -DPACKAGE_NAME=\"yaccpp2\" -DPACKAGE_TARNAME=\"yaccpp2\"
-DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"yaccpp2\ 1.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"yaccpp2\"
-DVERSION=\"1.0\" -I. -I..     -g -O2 -MT zardoz.o -MD -MP -MF
.deps/zardoz.Tpo -c -o zardoz.o zardoz.cc
zardoz.cc:49: fatal error: y.tab.h: No such file or directory
compilation terminated.

For a personal project, I made the following modifications to the
ylwrap script but I doubt that I have considered every possible usage
of ylwrap.

$ diff -u /usr/share/automake-1.11/ylwrap ylwrap
--- /usr/share/automake-1.11/ylwrap	2010-02-02 01:59:15.000000000 +0100
+++ ylwrap	2010-10-15 21:58:04.693283559 +0200
@@ -188,6 +188,17 @@
           mv -f "$target" "$realtarget"
         fi
       fi
+
+      # Update #include directives
+      case "$target" in
+	  *.cc)
+	      base=`basename $target .cc`
+	      mv $target $target.tmp
+	      sed "s/y.tab.h/$base.h/g" $target.tmp > $target
+	      rm $target.tmp
+	      ;;
+      esac
+
     else
       # A missing file is only an error for the first file.  This
       # is a blatant hack to let us support using "yacc -d".  If -d

Regards,

James
[bisonpp.test (application/octet-stream, attachment)]

Information forwarded to owner <at> debbugs.gnu.org, bug-automake <at> gnu.org:
bug#7648; Package automake. (Tue, 04 Jan 2011 22:30:04 GMT) Full text and rfc822 format available.

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: James Bostock <james.bostock <at> gmail.com>
Cc: 7648 <at> debbugs.gnu.org
Subject: Re: bug#7648: ylwrap appears not to support bison's lalr1.cc skeleton
Date: Tue, 4 Jan 2011 23:36:05 +0100
Hello James.

Thanks for your report, and sorry for the late reply.

On Wednesday 15 December 2010, James Bostock wrote:
> Hi,
> 
> Automake version 1.11.1
> Autoconf version 2.67
> Bison versions 1.875 and 2.4.1
> 
> If bison is directed to use the lalr1.cc skeleton file then although
> ylwrap renames the files generated by bison, it does not update the
> generated parser source code to #include the renamed header file.
>
Actually it's even worse than that: the generated y.tab.h "#include"s
two other bison-generated header files (stack.hh and location.hh) that
end up being removed by the ylwrap script!

JFTR, here is how that happens.  The ylwrap script works by doing a
chdir into a temporary directory, calling yacc from there, renaming
and editing the generated files, and then moving them back to the
original directory.  In your case, since ylwrap knows nothing about
the bison-generated 'stack.hh' and 'location.hh' header files, it
doesn't copy them back in the original directory, so that they are
lost when the temporary directory is removed.  D'oh!

I'm still undecided if at this point we should just (try to) rewrite
the messy ylwrap script, or if it would be better to teach automake
to recognize when it's using bison as $(YACC), and take advantage of
more bison features in this case -- which would probably allow to
bypass the use of ylwrap altogether.

> Attached is a test script that illustrates the problem.
> 
> In more detail, the generated parser tries to #include the file "y.tab.h":
> 
>  48
>  49 #include "y.tab.h"
>  50
> 
> But y.tab.h has been renamed to zardoz.h by ylwrap, causing compilation to fail:
> 
> $ make
> g++ -DPACKAGE_NAME=\"yaccpp2\" -DPACKAGE_TARNAME=\"yaccpp2\"
> -DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"yaccpp2\ 1.0\"
> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"yaccpp2\"
> -DVERSION=\"1.0\" -I. -I..     -g -O2 -MT zardoz.o -MD -MP -MF
> .deps/zardoz.Tpo -c -o zardoz.o zardoz.cc
> zardoz.cc:49: fatal error: y.tab.h: No such file or directory
> compilation terminated.
> 
> For a personal project, I made the following modifications to the
> ylwrap script but I doubt that I have considered every possible usage
> of ylwrap.
> 
> $ diff -u /usr/share/automake-1.11/ylwrap ylwrap
> --- /usr/share/automake-1.11/ylwrap	2010-02-02 01:59:15.000000000 +0100
> +++ ylwrap	2010-10-15 21:58:04.693283559 +0200
> @@ -188,6 +188,17 @@
>            mv -f "$target" "$realtarget"
>          fi
>        fi
> +
> +      # Update #include directives
> +      case "$target" in
> +	  *.cc)
> +	      base=`basename $target .cc`
> +	      mv $target $target.tmp
> +	      sed "s/y.tab.h/$base.h/g" $target.tmp > $target
> +	      rm $target.tmp
> +	      ;;
> +      esac
> +
>      else
>        # A missing file is only an error for the first file.  This
>        # is a blatant hack to let us support using "yacc -d".  If -d
>
Hmmm...  accordingly to my analysis above, this workaround is not
enough, and in fact it fails for me.  Does it really works for you?

> Regards,
> 
> James
> 

Thanks,
  Stefano




Information forwarded to owner <at> debbugs.gnu.org, bug-automake <at> gnu.org:
bug#7648; Package automake. (Wed, 05 Jan 2011 11:12:01 GMT) Full text and rfc822 format available.

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

From: James Bostock <james.bostock <at> gmail.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 7648 <at> debbugs.gnu.org
Subject: Re: bug#7648: ylwrap appears not to support bison's lalr1.cc skeleton
Date: Wed, 5 Jan 2011 12:18:39 +0100
And thank you for getting back to me. Given the time of year, I
wouldn't consider your reply late :). More inline below.

On Tue, Jan 4, 2011 at 11:36 PM, Stefano Lattarini
<stefano.lattarini <at> gmail.com> wrote:
> Hello James.
>
> Thanks for your report, and sorry for the late reply.
>
> On Wednesday 15 December 2010, James Bostock wrote:
>> Hi,
>>
>> Automake version 1.11.1
>> Autoconf version 2.67
>> Bison versions 1.875 and 2.4.1
>>
>> If bison is directed to use the lalr1.cc skeleton file then although
>> ylwrap renames the files generated by bison, it does not update the
>> generated parser source code to #include the renamed header file.
>>
> Actually it's even worse than that: the generated y.tab.h "#include"s
> two other bison-generated header files (stack.hh and location.hh) that
> end up being removed by the ylwrap script!

Yes, after submitting the bug report, I came across this too. The
reason that I didn't run across this from the outset is that while
trying to get things up and running, I ran bison manually and so these
files just happened to be lying around. Starting from scratch, I ran
into this and added another crude hack to the ylwrap script.

>
> JFTR, here is how that happens.  The ylwrap script works by doing a
> chdir into a temporary directory, calling yacc from there, renaming
> and editing the generated files, and then moving them back to the
> original directory.  In your case, since ylwrap knows nothing about
> the bison-generated 'stack.hh' and 'location.hh' header files, it
> doesn't copy them back in the original directory, so that they are
> lost when the temporary directory is removed.  D'oh!
>
> I'm still undecided if at this point we should just (try to) rewrite
> the messy ylwrap script, or if it would be better to teach automake
> to recognize when it's using bison as $(YACC), and take advantage of
> more bison features in this case -- which would probably allow to
> bypass the use of ylwrap altogether.

For what it's worth, I think the preferable solution would be to add
an AM_BISON macro to detect the presence of bison and, if it is
present, not use ylwrap at all as, unless in compatability mode,
bison's output files are named after the input grammar file anyway,
obviating the need for ylwrap. I had a look at the automake code but
as this doesn't seem to be trivial (at the same time, I don't think it
should be too complicated), I gave up on trying to do it myself.

>
>> Attached is a test script that illustrates the problem.
>>
>> In more detail, the generated parser tries to #include the file "y.tab.h":
>>
>>  48
>>  49 #include "y.tab.h"
>>  50
>>
>> But y.tab.h has been renamed to zardoz.h by ylwrap, causing compilation to fail:
>>
>> $ make
>> g++ -DPACKAGE_NAME=\"yaccpp2\" -DPACKAGE_TARNAME=\"yaccpp2\"
>> -DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"yaccpp2\ 1.0\"
>> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"yaccpp2\"
>> -DVERSION=\"1.0\" -I. -I..     -g -O2 -MT zardoz.o -MD -MP -MF
>> .deps/zardoz.Tpo -c -o zardoz.o zardoz.cc
>> zardoz.cc:49: fatal error: y.tab.h: No such file or directory
>> compilation terminated.
>>
>> For a personal project, I made the following modifications to the
>> ylwrap script but I doubt that I have considered every possible usage
>> of ylwrap.
>>
>> $ diff -u /usr/share/automake-1.11/ylwrap ylwrap
>> --- /usr/share/automake-1.11/ylwrap   2010-02-02 01:59:15.000000000 +0100
>> +++ ylwrap    2010-10-15 21:58:04.693283559 +0200
>> @@ -188,6 +188,17 @@
>>            mv -f "$target" "$realtarget"
>>          fi
>>        fi
>> +
>> +      # Update #include directives
>> +      case "$target" in
>> +       *.cc)
>> +           base=`basename $target .cc`
>> +           mv $target $target.tmp
>> +           sed "s/y.tab.h/$base.h/g" $target.tmp > $target
>> +           rm $target.tmp
>> +           ;;
>> +      esac
>> +
>>      else
>>        # A missing file is only an error for the first file.  This
>>        # is a blatant hack to let us support using "yacc -d".  If -d
>>
> Hmmm...  accordingly to my analysis above, this workaround is not
> enough, and in fact it fails for me.  Does it really works for you?

You are referring to the additional header files that bison generates
or is there some other problem that you see? Adding support for the
location.hh and stack.hh header files (elsewhere in the script), the
change above does seem to work for me.

>
>> Regards,
>>
>> James
>>
>
> Thanks,
>  Stefano
>

Regards,

James




Information forwarded to owner <at> debbugs.gnu.org, bug-automake <at> gnu.org:
bug#7648; Package automake. (Wed, 05 Jan 2011 19:26:02 GMT) Full text and rfc822 format available.

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: James Bostock <james.bostock <at> gmail.com>
Cc: 7648 <at> debbugs.gnu.org
Subject: Re: bug#7648: ylwrap appears not to support bison's lalr1.cc skeleton
Date: Wed, 5 Jan 2011 20:32:10 +0100
On Wednesday 05 January 2011, James Bostock wrote:
> And thank you for getting back to me. Given the time of year, I
> wouldn't consider your reply late :). More inline below.
> 
> On Tue, Jan 4, 2011 at 11:36 PM, Stefano Lattarini
> <stefano.lattarini <at> gmail.com> wrote:
> > Hello James.
> >
> > Thanks for your report, and sorry for the late reply.
> >
> > On Wednesday 15 December 2010, James Bostock wrote:
> >> Hi,
> >>
> >> Automake version 1.11.1
> >> Autoconf version 2.67
> >> Bison versions 1.875 and 2.4.1
> >>
> >> If bison is directed to use the lalr1.cc skeleton file then although
> >> ylwrap renames the files generated by bison, it does not update the
> >> generated parser source code to #include the renamed header file.
> >>
> > Actually it's even worse than that: the generated y.tab.h "#include"s
> > two other bison-generated header files (stack.hh and location.hh) that
> > end up being removed by the ylwrap script!
> 
> Yes, after submitting the bug report, I came across this too. The
> reason that I didn't run across this from the outset is that while
> trying to get things up and running, I ran bison manually and so these
> files just happened to be lying around. Starting from scratch, I ran
> into this and added another crude hack to the ylwrap script.
>
OK, all makes sense now.  Thanks for letting us know!

> >
> > JFTR, here is how that happens.  The ylwrap script works by doing a
> > chdir into a temporary directory, calling yacc from there, renaming
> > and editing the generated files, and then moving them back to the
> > original directory.  In your case, since ylwrap knows nothing about
> > the bison-generated 'stack.hh' and 'location.hh' header files, it
> > doesn't copy them back in the original directory, so that they are
> > lost when the temporary directory is removed.  D'oh!
> >
> > I'm still undecided if at this point we should just (try to) rewrite
> > the messy ylwrap script, or if it would be better to teach automake
> > to recognize when it's using bison as $(YACC), and take advantage of
> > more bison features in this case -- which would probably allow to
> > bypass the use of ylwrap altogether.
> 
> For what it's worth, I think the preferable solution would be to add
> an AM_BISON macro to detect the presence of bison and, if it is
> present, not use ylwrap at all as, unless in compatability mode,
> bison's output files are named after the input grammar file anyway,
> obviating the need for ylwrap.
>
Hmm... I agree, especially because most of the problems of ylwrap derive
anyway from the use of bison-specific flags and features.

If the change you propose is implemented, than:
 - either you avoid to use bison-specific features in you packages,
   and in this case AC_PROG_YACC and ylwrap should be good enough; or:
 - you use the new AM_PROG_BISON macro, bypassing ylwrap completely,
   (and living happier probably :-).

> I had a look at the automake code but
> as this doesn't seem to be trivial (at the same time, I don't think it
> should be too complicated), I gave up on trying to do it myself.
>
I'll put writing a patch about this issue on my TODO list; I agree
it shouldn't be too complicated (and will give me an excuse to add
more tests about Yacc support ;-)

> >
> >> Attached is a test script that illustrates the problem.
> >>
> >> In more detail, the generated parser tries to #include the file "y.tab.h":
> >>
> >>  48
> >>  49 #include "y.tab.h"
> >>  50
> >>
> >> But y.tab.h has been renamed to zardoz.h by ylwrap, causing compilation to fail:
> >>
> >> $ make
> >> g++ -DPACKAGE_NAME=\"yaccpp2\" -DPACKAGE_TARNAME=\"yaccpp2\"
> >> -DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"yaccpp2\ 1.0\"
> >> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"yaccpp2\"
> >> -DVERSION=\"1.0\" -I. -I..     -g -O2 -MT zardoz.o -MD -MP -MF
> >> .deps/zardoz.Tpo -c -o zardoz.o zardoz.cc
> >> zardoz.cc:49: fatal error: y.tab.h: No such file or directory
> >> compilation terminated.
> >>
> >> For a personal project, I made the following modifications to the
> >> ylwrap script but I doubt that I have considered every possible usage
> >> of ylwrap.
> >>
> >> $ diff -u /usr/share/automake-1.11/ylwrap ylwrap
> >> --- /usr/share/automake-1.11/ylwrap   2010-02-02 01:59:15.000000000 +0100
> >> +++ ylwrap    2010-10-15 21:58:04.693283559 +0200
> >> @@ -188,6 +188,17 @@
> >>            mv -f "$target" "$realtarget"
> >>          fi
> >>        fi
> >> +
> >> +      # Update #include directives
> >> +      case "$target" in
> >> +       *.cc)
> >> +           base=`basename $target .cc`
> >> +           mv $target $target.tmp
> >> +           sed "s/y.tab.h/$base.h/g" $target.tmp > $target
> >> +           rm $target.tmp
> >> +           ;;
> >> +      esac
> >> +
> >>      else
> >>        # A missing file is only an error for the first file.  This
> >>        # is a blatant hack to let us support using "yacc -d".  If -d
> >>
> > Hmmm...  accordingly to my analysis above, this workaround is not
> > enough, and in fact it fails for me.  Does it really works for you?
> 
> You are referring to the additional header files that bison generates
>
Yes, and your explanation above dissolved my doubts about this issue.

> or is there some other problem that you see?
>
Nope.

> Adding support for the location.hh and stack.hh header files (elsewhere
> in the script), the change above does seem to work for me.
>
Exactly.

Thanks,
   Stefano




Information forwarded to owner <at> debbugs.gnu.org, bug-automake <at> gnu.org:
bug#7648; Package automake. (Tue, 18 Jan 2011 13:23:02 GMT) Full text and rfc822 format available.

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: James Bostock <james.bostock <at> gmail.com>
Cc: 7648 <at> debbugs.gnu.org
Subject: Re: bug#7648: ylwrap appears not to support bison's lalr1.cc skeleton
Date: Tue, 18 Jan 2011 14:29:24 +0100
Hello automakers, James.

JFTR, the "renamed header" part of this bug:

 > On Wednesday 15 December 2010, James Bostock wrote:
 >> Hi,
 >>
 >> Automake version 1.11.1
 >> Autoconf version 2.67
 >> Bison versions 1.875 and 2.4.1
 >>
 >> If bison is directed to use the lalr1.cc skeleton file then although
 >> ylwrap renames the files generated by bison, it does not update the
 >> generated parser source code to #include the renamed header file.

had already been reported in PR automake/491 (dating back to 2006!):
 <http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=automake&pr=491>

Another good reason to fix the bug before the next release, I'd say.
I still plan to (try to) do so myself, even if not right away (but
hopefully, soonish enough).

Regards,
  Stefano




Information forwarded to owner <at> debbugs.gnu.org, bug-automake <at> gnu.org:
bug#7648; Package automake. (Fri, 28 Jan 2011 12:59:02 GMT) Full text and rfc822 format available.

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: automake-patches <at> gnu.org
Cc: 7648 <at> debbugs.gnu.org, James Bostock <james.bostock <at> gmail.com>
Subject: [PATCH] {yacc-work} yacc: extension of headers modelled after
	extension of sources
Date: Fri, 28 Jan 2011 14:06:23 +0100
[Message part 1 (text/plain, inline)]
Hello automakers.  The reasons of this patch should be
explained in details in the ChangeLog entry (see below).

OK for the 'yacc-work' branch?

Regards,
   Stefano

-*-*-

With this change, if '-d' is in *YFLAGS, a yacc input file named
foo.y++ will cause a foo.h++ header to be generated, instead of a
foo.h header.  Similarly for foo.ypp, foo.yxx and foo.yy.
This way, the name of the files generated by an automake-created
`ylwrap' invocation should be consistent with those generated by
a `bison -o' call.

Related to automake bug#7648 and PR automake/491.

* lib/am/yacc.am (am__yacc_c2h): New internal variable.
(?GENERIC?%EXT%%DERIVED-EXT%, ?!GENERIC?%OBJ%): Get the name of
the header dynamically at make runtime, so that its extension is
modelled after the extension of the source.
* automake.in (lang_yacc_target_hook): Adjust the calculation of
`$header' accordingly.
* tests/yacc-cxx.test: New test.
* tests/yacc-d-cxx.test: Likewise.
* tests/yacc-weirdnames.test: Likewise.
* tests/yacc-basic.test: Update comments.
* tests/yacc-d-basic.test: Likewise.
* tests/yaccpp.test: Updated and extended.
* tests/Makefile.am (TESTS): Update.
[0001-yacc-extension-of-headers-modelled-after-extension-o.patch (text/x-patch, inline)]
From e3d6064f7faf582d70871bed40a9d19c9d4c98d4 Mon Sep 17 00:00:00 2001
From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Date: Fri, 21 Jan 2011 17:47:42 +0100
Subject: [PATCH] yacc: extension of headers modelled after extension of sources

With this change, if '-d' is in *YFLAGS, a yacc input file named
foo.y++ will cause a foo.h++ header to be generated, instead of a
foo.h header.  Similarly for foo.ypp, foo.yxx and foo.yy.
This way, the name of the files generated by an automake-created
`ylwrap' invocation should be consistent with those generated by
a `bison -o' call.

Related to automake bug#7648 and PR automake/491.

* lib/am/yacc.am (am__yacc_c2h): New internal variable.
(?GENERIC?%EXT%%DERIVED-EXT%, ?!GENERIC?%OBJ%): Get the name of
the header dynamically at make runtime, so that its extension is
modelled after the extension of the source.
* automake.in (lang_yacc_target_hook): Adjust the calculation of
`$header' accordingly.
* tests/yacc-cxx.test: New test.
* tests/yacc-d-cxx.test: Likewise.
* tests/yacc-weirdnames.test: Likewise.
* tests/yacc-basic.test: Update comments.
* tests/yacc-d-basic.test: Likewise.
* tests/yaccpp.test: Updated and extended.
* tests/Makefile.am (TESTS): Update.
---
 ChangeLog                  |   24 +++++
 automake.in                |   20 ++++-
 lib/am/yacc.am             |   11 ++-
 tests/Makefile.am          |    3 +
 tests/Makefile.in          |    3 +
 tests/yacc-basic.test      |    3 +-
 tests/yacc-cxx.test        |  138 ++++++++++++++++++++++++++
 tests/yacc-d-basic.test    |    7 +-
 tests/yacc-d-cxx.test      |  229 ++++++++++++++++++++++++++++++++++++++++++++
 tests/yacc-weirdnames.test |   56 +++++++++++
 tests/yaccpp.test          |   41 ++++++++-
 11 files changed, 522 insertions(+), 13 deletions(-)
 create mode 100755 tests/yacc-cxx.test
 create mode 100755 tests/yacc-d-cxx.test
 create mode 100755 tests/yacc-weirdnames.test

diff --git a/ChangeLog b/ChangeLog
index 31adec7..054ac58 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,27 @@
+2011-01-28   Stefano Lattarini  <stefano.lattarini <at> gmail.com>
+
+	yacc: extension of headers modelled after extension of sources
+	With this change, if '-d' is in *YFLAGS, a yacc input file named
+	foo.y++ will cause a foo.h++ header to be generated, instead of a
+	foo.h header.  Similarly for foo.ypp, foo.yxx and foo.yy.
+	This way, the name of the files generated by an automake-created
+	`ylwrap' invocation should be consistent with those generated by
+	a `bison -o' call.
+	Related to automake bug#7648 and PR automake/491.
+	* lib/am/yacc.am (am__yacc_c2h): New internal variable.
+	(?GENERIC?%EXT%%DERIVED-EXT%, ?!GENERIC?%OBJ%): Get the name of
+	the header dynamically at make runtime, so that its extension is
+	modelled after the extension of the source.
+	* automake.in (lang_yacc_target_hook): Adjust the calculation of
+	`$header' accordingly.
+	* tests/yacc-cxx.test: New test.
+	* tests/yacc-d-cxx.test: Likewise.
+	* tests/yacc-weirdnames.test: Likewise.
+	* tests/yacc-basic.test: Update comments.
+	* tests/yacc-d-basic.test: Likewise.
+	* tests/yaccpp.test: Updated and extended.
+	* tests/Makefile.am (TESTS): Update.
+
 2011-01-12   Stefano Lattarini  <stefano.lattarini <at> gmail.com>
 
 	docs: clustered '-d' not recognized in YFLAGS
diff --git a/automake.in b/automake.in
index fa458d6..e2e67b9 100755
--- a/automake.in
+++ b/automake.in
@@ -6084,12 +6084,26 @@ sub lang_yacc_target_hook
 
     if ($yflags_contains_minus_d)
       {
-	(my $output_base = $output) =~ s/$KNOWN_EXTENSIONS_PATTERN$//;
-	my $header = $output_base . '.h';
-
 	# Found a `-d' that applies to the compilation of this file.
 	# Add a dependency for the generated header file, and arrange
 	# for that file to be included in the distribution.
+
+	# The extension of the output file (e.g., `.c' or `.cxx').
+	# We'll need it to compute the name of the generated header file.
+	(my $output_ext = basename ($output)) =~ s/.*(\.[^.]+)$/$1/;
+
+	# We know that a yacc input should be turned into either a C or
+	# C++ output file.  We depend on this fact (here and in yacc.am),
+	# so check that it really holds.
+	my $lang = $languages{$extension_map{$output_ext}};
+	prog_error "invalid output name `$output' for yacc file `$input'"
+	  if (!$lang || ($lang->name ne 'c' && $lang->name ne 'cxx'));
+
+	(my $header_ext = $output_ext) =~ s/c/h/g;
+        # Quote $output_ext in the regexp, so that dots in it are taken
+        # as literal dots, not as metacharacters.
+	(my $header = $output) =~ s/\Q$output_ext\E$/$header_ext/;
+
 	foreach my $cond (Automake::Rule::define (${header}, 'internal',
 						  RULE_AUTOMAKE, TRUE,
 						  INTERNAL))
diff --git a/lib/am/yacc.am b/lib/am/yacc.am
index 6d35cd4..8ad4074 100644
--- a/lib/am/yacc.am
+++ b/lib/am/yacc.am
@@ -33,16 +33,19 @@
 ## distributed or not.  We cannot have a generic rule that works in
 ## both cases, so we ensure in automake that nodist_ parsers always
 ## use non-generic rules.
-if %?MAINTAINER-MODE%
 if %?FIRST%
+if %?MAINTAINER-MODE%
 @MAINTAINER_MODE_FALSE <at> am__skipyacc = test -f $@ ||
-endif %?FIRST%
 endif %?MAINTAINER-MODE%
+## The 's/c$/h/' substitution *must* be the last one.
+am__yacc_c2h = sed -e s/cc$$/hh/ -e s/cpp$$/hpp/ -e s/cxx$$/hxx/ \
+		   -e s/c++$$/h++/ -e s/c$$/h/
+endif %?FIRST%
 
 ?GENERIC?%EXT%%DERIVED-EXT%:
 ?!GENERIC?%OBJ%: %SOURCE%
-?GENERIC?	%VERBOSE%$(am__skipyacc) $(SHELL) $(YLWRAP) %SOURCE% y.tab.c %OBJ% y.tab.h %BASE%.h y.output %BASE%.output -- %COMPILE%
+?GENERIC?	%VERBOSE%$(am__skipyacc) $(SHELL) $(YLWRAP) %SOURCE% y.tab.c %OBJ% y.tab.h `echo %OBJ% | $(am__yacc_c2h)` y.output %BASE%.output -- %COMPILE%
 ?!GENERIC?	%VERBOSE% \
 ?!GENERIC??DIST_SOURCE?	$(am__skipyacc) \
 ## For non-suffix rules, we must emulate a VPATH search on %SOURCE%.
-?!GENERIC?	$(SHELL) $(YLWRAP) `test -f '%SOURCE%' || echo '$(srcdir)/'`%SOURCE% y.tab.c %OBJ% y.tab.h %BASE%.h y.output %BASE%.output -- %COMPILE%
+?!GENERIC?	$(SHELL) $(YLWRAP) `test -f '%SOURCE%' || echo '$(srcdir)/'`%SOURCE% y.tab.c %OBJ% y.tab.h `echo %OBJ% | $(am__yacc_c2h)` y.output %BASE%.output -- %COMPILE%
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 39f1a39..6230466 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -797,6 +797,8 @@ xsource.test \
 xz.test \
 yacc-basic.test \
 yacc-d-basic.test \
+yacc-cxx.test \
+yacc-d-cxx.test \
 yacc-clean.test \
 yacc.test \
 yacc2.test \
@@ -811,6 +813,7 @@ yacc-nodist.test \
 yaccpp.test \
 yaccvpath.test \
 yacc-d-vpath.test \
+yacc-weirdnames.test \
 yflags.test \
 yflags2.test \
 yflags-cmdline-override.test \
diff --git a/tests/Makefile.in b/tests/Makefile.in
index 0ea9825..060bd83 100644
--- a/tests/Makefile.in
+++ b/tests/Makefile.in
@@ -1064,6 +1064,8 @@ xsource.test \
 xz.test \
 yacc-basic.test \
 yacc-d-basic.test \
+yacc-cxx.test \
+yacc-d-cxx.test \
 yacc-clean.test \
 yacc.test \
 yacc2.test \
@@ -1078,6 +1080,7 @@ yacc-nodist.test \
 yaccpp.test \
 yaccvpath.test \
 yacc-d-vpath.test \
+yacc-weirdnames.test \
 yflags.test \
 yflags2.test \
 yflags-cmdline-override.test \
diff --git a/tests/yacc-basic.test b/tests/yacc-basic.test
index 4faea95..9e87cbb 100755
--- a/tests/yacc-basic.test
+++ b/tests/yacc-basic.test
@@ -14,7 +14,8 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
-# Basic semantic checks on Yacc support.
+# Basic semantic checks on Yacc support (without yacc-generated headers).
+# Keep in sync with sister test `yacc-cxx.test'.
 
 required=yacc
 . ./defs || Exit 1
diff --git a/tests/yacc-cxx.test b/tests/yacc-cxx.test
new file mode 100755
index 0000000..86693d6
--- /dev/null
+++ b/tests/yacc-cxx.test
@@ -0,0 +1,138 @@
+#! /bin/sh
+# Copyright (C) 2011 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/>.
+
+# Basic semantic checks on Yacc + C++ support (when yacc-generated
+# headers are not involved).
+# Keep in sync with sister test `yacc-basic.test'.
+
+required=yacc
+. ./defs || Exit 1
+
+distdir=$me-1.0
+
+cat >> configure.in << 'END'
+AC_PROG_CXX
+AC_PROG_YACC
+AC_OUTPUT
+END
+
+cat > Makefile.am << 'END'
+bin_PROGRAMS = foo1 foo2 foo3 foo4
+foo1_SOURCES = parse1.yy  foo.cc
+foo2_SOURCES = parse2.y++ bar.c++
+foo3_SOURCES = parse3.yxx foo.cc
+foo4_SOURCES = parse4.ypp bar.cxx
+foo3_YFLAGS = -v
+foo4_YFLAGS = $(foo3_YFLAGS)
+
+.PHONY: echo-distcom
+echo-distcom:
+	@echo ' ' $(DIST_COMMON) ' '
+END
+
+cat > parse1.yy << 'END'
+%{
+// Valid as C++, but deliberatly invalid as C.
+#include <cstdio>
+#include <cstdlib>
+int yylex (void) { return (getchar ()); }
+void yyerror (const char *s) { return; }
+%}
+%%
+a : 'a' { exit(0); };
+END
+cp parse1.yy parse2.y++
+cp parse1.yy parse3.yxx
+cp parse1.yy parse4.ypp
+
+cat > foo.cc << 'END'
+// Valid as C++, but deliberatly invalid as C.
+using namespace std;
+int main (int argc, char **argv)
+{
+  int yyparse (void);
+  yyparse ();
+  return 1;
+}
+END
+cp foo.cc bar.c++
+cp foo.cc bar.cxx
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE -a
+
+./configure
+
+$MAKE
+
+# The Yacc-derived C++ sources must be created, and not removed once
+# compiled (i.e., not treated like "intermediate files" in the GNU
+# make sense).
+test -f parse1.cc
+test -f parse2.c++
+test -f foo3-parse3.cxx
+test -f foo4-parse4.cpp
+# Check that per-object flags are honored.
+test -f foo3-parse3.output
+test -f foo4-parse4.output
+
+for i in 1 2 3 4; do
+  echo a | ./foo$i
+  echo b | ./foo$i && Exit 1
+done
+
+# The Yacc-derived C++ sources must be shipped.
+$MAKE echo-distcom
+$MAKE -s echo-distcom | grep '[ /]parse1\.cc '
+$MAKE -s echo-distcom | grep '[ /]parse2\.c++ '
+$MAKE -s echo-distcom | grep '[ /]foo3-parse3\.cxx '
+$MAKE -s echo-distcom | grep '[ /]foo4-parse4\.cpp '
+$MAKE distdir
+ls -l $distdir
+test -f $distdir/parse1.cc
+test -f $distdir/parse2.c++
+test -f $distdir/foo3-parse3.cxx
+test -f $distdir/foo4-parse4.cpp
+
+# Sanity check on distribution.
+# Note that, for this to succeed, foo3-parse3.output and foo4-parse4.output
+# must either not be distributed, or properly cleaned by automake-generated
+# rules.  We don't want to set the exact semantics yet, but want to ensure
+# they are are consistent.
+$MAKE distcheck
+
+# Make sure that the Yacc-derived C++ sources are erased by
+# maintainer-clean, and not by distclean.
+test -f parse1.cc
+test -f parse2.c++
+test -f foo3-parse3.cxx
+test -f foo4-parse4.cpp
+$MAKE distclean
+ls -l
+test -f parse1.cc
+test -f parse2.c++
+test -f foo3-parse3.cxx
+test -f foo4-parse4.cpp
+./configure # we must re-create `Makefile'
+$MAKE maintainer-clean
+ls -l
+test ! -f parse1.cc
+test ! -f parse2.c++
+test ! -f foo3-parse3.cxx
+test ! -f foo4-parse4.cpp
+
+:
diff --git a/tests/yacc-d-basic.test b/tests/yacc-d-basic.test
index 11e5ba3..6cb5e99 100755
--- a/tests/yacc-d-basic.test
+++ b/tests/yacc-d-basic.test
@@ -14,8 +14,9 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
-# Tests on basic Yacc support for when we have -d in YFLAGS, AM_YFLAGS
-# or maude_YFLAGS.
+# Tests Yacc support with yacc-generated headers
+# (i.e., '-d' in *YFLAGS).
+# Keep in sync with sister test `yacc-d-cxx.test'.
 
 required=yacc
 . ./defs || Exit 1
@@ -111,7 +112,7 @@ test -f bar/parse.h
 test -f baz/zardoz-parse.c
 test -f baz/zardoz-parse.h
 
-# The generated C and header files must be shipped.
+# The generated C source and header files must be shipped.
 for dir in foo bar; do
   cd $dir
   $MAKE echo-distcom
diff --git a/tests/yacc-d-cxx.test b/tests/yacc-d-cxx.test
new file mode 100755
index 0000000..b94b14d
--- /dev/null
+++ b/tests/yacc-d-cxx.test
@@ -0,0 +1,229 @@
+#! /bin/sh
+# Copyright (C) 2011 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/>.
+
+# Various tests on Yacc/C++ support with yacc-generated headers
+# (i.e., '-d' in *YFLAGS).
+# Keep in sync with sister test `yacc-d-basic.test'.
+
+required=yacc
+. ./defs || Exit 1
+
+set -e
+
+tab='	'
+distdir=$me-1.0
+
+write_parse ()
+{
+  header=$1
+  sed 's/^ *//' <<END
+    %{
+    // Valid as C++, but deliberatly invalid as C.
+    #include <cstdlib>
+    #include "$header"
+    int yylex (void) { return 0; }
+    void yyerror (const char *s) {}
+    %}
+    %%
+    x : 'x' {};
+    %%
+END
+}
+
+write_main ()
+{
+  header=$1
+  sed 's/^ *//' <<END
+    // Valid as C++, but deliberatly invalid as C.
+    #include <cstdio>
+    #include "$header"
+    int main (int argc, char **argv)
+    {
+      int yyparse (void);
+      return yyparse ();
+    }
+END
+}
+
+cat >> configure.in << 'END'
+AC_PROG_CXX
+AC_PROG_YACC
+AC_CONFIG_FILES([foo/Makefile bar/Makefile baz/Makefile qux/Makefile])
+AC_OUTPUT
+END
+
+cat > Makefile.am <<'END'
+SUBDIRS = foo bar baz qux
+END
+
+mkdir foo bar baz qux baz/sub
+
+# These makefiles will be extended later.
+cat > foo/Makefile.am <<'END'
+.PHONY: echo-distcom
+echo-distcom:
+	@echo ' ' $(DIST_COMMON) ' '
+END
+cp foo/Makefile.am bar/Makefile.am
+cp foo/Makefile.am baz/Makefile.am
+cp foo/Makefile.am qux/Makefile.am
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE Makefile
+
+cp $testsrcdir/../lib/ylwrap .
+
+# Try with -d in $(YFLAGS) (don't do this in real life!).
+cat >> foo/Makefile.am <<END
+bin_PROGRAMS = zardoz
+zardoz_SOURCES = parse.yy main.cc
+BUILT_SOURCES = parse.hh
+YFLAGS=\
+-d
+END
+
+$AUTOMAKE -Wno-gnu foo/Makefile
+
+write_parse parse.hh > foo/parse.yy
+write_main parse.hh > foo/main.cc
+
+# Try with -d in $(AM_YFLAGS).
+cat >> bar/Makefile.am <<END
+bin_PROGRAMS = zardoz
+zardoz_SOURCES = parse.ypp main.cpp
+BUILT_SOURCES = parse.hpp
+AM_YFLAGS${tab}=  -d ${tab}
+END
+
+$AUTOMAKE bar/Makefile
+
+write_parse parse.hpp > bar/parse.ypp
+write_main parse.hpp > bar/main.cpp
+
+# Try with -d in $(AM_YFLAGS), and a subdir parser.
+cat >> baz/Makefile.am <<END
+AUTOMAKE_OPTIONS = subdir-objects
+bin_PROGRAMS = joe
+joe_SOURCES = sub/parse.y++ sub/main.c++
+BUILT_SOURCES = sub/parse.h++
+AM_YFLAGS = \
+${tab}-d
+END
+
+$AUTOMAKE baz/Makefile
+
+write_parse sub/parse.h++ > baz/sub/parse.y++
+write_main sub/parse.h++ > baz/sub/main.c++
+
+# Try with -d in $(xxx_YFLAGS) (per-object flag).
+cat >> qux/Makefile.am <<END
+bin_PROGRAMS = maude
+maude_SOURCES = parse.yxx main.cxx
+maude_YFLAGS=${tab}  -d${tab}
+BUILT_SOURCES = maude-parse.hxx
+END
+
+$AUTOMAKE qux/Makefile
+
+write_parse maude-parse.hxx > qux/parse.yxx
+write_main maude-parse.hxx > qux/main.cxx
+
+./configure
+
+$MAKE
+ls -l . foo bar baz baz/sub qux # For debugging.
+
+test -f foo/parse.cc
+test -f foo/parse.hh
+test -f bar/parse.cpp
+test -f bar/parse.hpp
+test -f baz/sub/parse.c++
+test -f baz/sub/parse.h++
+test -f qux/maude-parse.cxx
+test -f qux/maude-parse.hxx
+
+# The generated C++ source and header files must be shipped.
+cd foo
+$MAKE echo-distcom
+$MAKE -s echo-distcom | grep '[ /]parse\.cc '
+$MAKE -s echo-distcom | grep '[ /]parse\.hh '
+cd ..
+cd bar
+$MAKE echo-distcom
+$MAKE -s echo-distcom | grep '[ /]parse\.cpp '
+$MAKE -s echo-distcom | grep '[ /]parse\.hpp '
+cd ..
+cd baz
+$MAKE echo-distcom
+$MAKE -s echo-distcom | grep '[ /]sub/parse\.c++ '
+$MAKE -s echo-distcom | grep '[ /]sub/parse\.h++ '
+cd ..
+cd qux
+$MAKE echo-distcom
+$MAKE -s echo-distcom | grep '[ /]maude-parse\.cxx '
+$MAKE -s echo-distcom | grep '[ /]maude-parse\.hxx '
+cd ..
+
+$MAKE distdir
+find $distdir # For debugging.
+
+test -f $distdir/foo/parse.cc
+test -f $distdir/foo/parse.hh
+test -f $distdir/bar/parse.cpp
+test -f $distdir/bar/parse.hpp
+test -f $distdir/baz/sub/parse.c++
+test -f $distdir/baz/sub/parse.h++
+test -f $distdir/qux/maude-parse.cxx
+test -f $distdir/qux/maude-parse.hxx
+
+# The Yacc-derived C++ sources must be created, and not removed once
+# compiled (i.e., not treated like "intermediate files" in the GNU
+# make sense).
+$MAKE distcheck
+
+# Check that we can recover from deleted headers.
+$MAKE clean
+rm -f foo/parse.hh bar/parse.hpp baz/sub/parse.h++ qux/maude-parse.hxx
+$MAKE
+test -f foo/parse.hh
+test -f bar/parse.hpp
+test -f baz/sub/parse.h++
+test -f qux/maude-parse.hxx
+
+# Make sure that the Yacc-derived C++ sources are erased by
+# maintainer-clean, and not by distclean.
+$MAKE distclean
+test -f foo/parse.cc
+test -f foo/parse.hh
+test -f bar/parse.cpp
+test -f bar/parse.hpp
+test -f baz/sub/parse.c++
+test -f baz/sub/parse.h++
+test -f qux/maude-parse.cxx
+test -f qux/maude-parse.hxx
+./configure # We must re-create `Makefile'.
+$MAKE maintainer-clean
+test ! -f foo/parse.cc
+test ! -f foo/parse.hh
+test ! -f bar/parse.cpp
+test ! -f bar/parse.hpp
+test ! -f baz/sub/parse.c++
+test ! -f baz/sub/parse.h++
+test ! -f qux/maude-parse.cxx
+test ! -f qux/maude-parse.hxx
+
+:
diff --git a/tests/yacc-weirdnames.test b/tests/yacc-weirdnames.test
new file mode 100755
index 0000000..8f0424e
--- /dev/null
+++ b/tests/yacc-weirdnames.test
@@ -0,0 +1,56 @@
+#! /bin/sh
+# Copyright (C) 2011 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/>.
+
+# Check that yacc sources with many dots in their name are handled
+# correctly.
+
+. ./defs || Exit 1
+
+set -e
+
+cat >> configure.in << 'END'
+AC_PROG_CC
+AC_PROG_CXX
+AC_PROG_YACC
+AC_OUTPUT
+END
+
+cat > Makefile.am << 'END'
+bin_PROGRAMS = foo bar foo2 bar2
+
+foo_SOURCES = parse.y.y
+bar_SOURCES = parse.s.f..y
+bar_YFLAGS = -d
+
+foo2_SOURCES = parse..5.y++
+bar2_SOURCES = parse.yxx.yy
+bar2_YFLAGS = -d
+END
+
+outputs=' parse.y.c      bar-parse.s.f..c   bar-parse.s.f..h
+          parse..5.c++   bar2-parse.yxx.cc  bar2-parse.yxx.hh '
+
+$ACLOCAL
+$AUTOMAKE -a
+
+$EGREP '(\.[ch]|parse)' Makefile.in # For debugging.
+
+# All expected files should be mentioned in the generated Makefile.in.
+for s in $outputs; do
+  $FGREP $s Makefile.in
+done
+
+:
diff --git a/tests/yaccpp.test b/tests/yaccpp.test
index 9c4ae24..e5c9e31 100755
--- a/tests/yaccpp.test
+++ b/tests/yaccpp.test
@@ -15,8 +15,10 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
-# Test to make sure Yacc + C++ is supported.
-# Please keep this is sync with sister test lexcpp.test.
+# Test to make sure Yacc + C++ is not obviously broken.
+# See also related tests `yacc-cxx.test' and `yacc-d-cxx.test',
+# which does much more in-depth checks (but requires an actual
+# Yacc program and a working C++ compiler).
 
 . ./defs || Exit 1
 
@@ -38,10 +40,45 @@ END
 $ACLOCAL
 $AUTOMAKE -a
 
+$EGREP '(\.[ch]|foo|bar|baz|qux)' Makefile.in # For debugging.
+
+$EGREP '(foo|bar|baz|qux)\.h' Makefile.in && Exit 1
+
 sed -e 's/^/ /' -e 's/$/ /' Makefile.in >mk
+
 $FGREP ' foo.c++ ' mk
 $FGREP ' bar.cpp ' mk
 $FGREP ' baz.cc '  mk
 $FGREP ' qux.cxx ' mk
 
+cat >> Makefile.am <<END
+AM_YFLAGS = -d
+qux_YFLAGS = foo
+END
+
+$AUTOMAKE
+
+$EGREP '(\.[ch]|foo|bar|baz|qux)' Makefile.in # For debugging.
+
+sed -e 's/^/ /' -e 's/$/ /' Makefile.in >mk
+
+$FGREP ' foo.c++ ' mk
+$FGREP ' foo.h++ ' mk
+$FGREP ' bar.cpp ' mk
+$FGREP ' bar.hpp ' mk
+$FGREP ' baz.cc '  mk
+$FGREP ' baz.hh '  mk
+
+$EGREP '(^| )foo\.h\+\+(:| .*:)' Makefile.in
+$EGREP '(^| )bar\.hpp(:| .*:)'   Makefile.in
+$EGREP '(^| )baz\.hh(:| .*:)'    Makefile.in
+
+grep ' foo\.h[ :]' mk && Exit 1
+grep ' bar\.h[ :]' mk && Exit 1
+grep ' baz\.h[ :]' mk && Exit 1
+
+$FGREP ' qux-qux.cxx ' mk
+$EGREP '(^| )qux-qux\.cxx(:| .*:)' Makefile.in
+grep 'qux\.h.*:' Makefile.in && Exit 1
+
 :
-- 
1.7.2.3


Information forwarded to owner <at> debbugs.gnu.org, bug-automake <at> gnu.org:
bug#7648; Package automake. (Sun, 10 Apr 2011 08:27:01 GMT) Full text and rfc822 format available.

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: automake-patches <at> gnu.org
Cc: 7648 <at> debbugs.gnu.org, James Bostock <james.bostock <at> gmail.com>
Subject: Re: bug#7648: [PATCH] {yacc-work} yacc: extension of headers modelled
	after extension of sources
Date: Sun, 10 Apr 2011 10:26:40 +0200
Reference:
 <http://lists.gnu.org/archive/html/automake-patches/2011-01/msg00306.html>

On Friday 28 January 2011, Stefano Lattarini wrote:
> Hello automakers.  The reasons of this patch should be
> explained in details in the ChangeLog entry (see below).
> 
> OK for the 'yacc-work' branch?
> 
> Regards,
>    Stefano
> 
> -*-*-
> 
> With this change, if '-d' is in *YFLAGS, a yacc input file named
> foo.y++ will cause a foo.h++ header to be generated, instead of a
> foo.h header.  Similarly for foo.ypp, foo.yxx and foo.yy.
> This way, the name of the files generated by an automake-created
> `ylwrap' invocation should be consistent with those generated by
> a `bison -o' call.
> 
> Related to automake bug#7648 and PR automake/491.
> 
> * lib/am/yacc.am (am__yacc_c2h): New internal variable.
> (?GENERIC?%EXT%%DERIVED-EXT%, ?!GENERIC?%OBJ%): Get the name of
> the header dynamically at make runtime, so that its extension is
> modelled after the extension of the source.
> * automake.in (lang_yacc_target_hook): Adjust the calculation of
> `$header' accordingly.
> * tests/yacc-cxx.test: New test.
> * tests/yacc-d-cxx.test: Likewise.
> * tests/yacc-weirdnames.test: Likewise.
> * tests/yacc-basic.test: Update comments.
> * tests/yacc-d-basic.test: Likewise.
> * tests/yaccpp.test: Updated and extended.
> * tests/Makefile.am (TESTS): Update.
> 
This patch has been applied in the meantime, but it lacked NEWS and
documentation updates.  I will post them soonish in two different
patches.

Sorry for the noise,
  Stefano




Information forwarded to owner <at> debbugs.gnu.org, bug-automake <at> gnu.org:
bug#7648; Package automake. (Thu, 12 May 2011 16:28:02 GMT) Full text and rfc822 format available.

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: James Bostock <james.bostock <at> gmail.com>
Cc: 7648 <at> debbugs.gnu.org, automake <at> gnu.org
Subject: Automake yacc support, GNU bison,
	and non-standard generated headers (was: Re: bug#7648: ylwrap appears
	not to support bison's lalr1.cc skeleton)
Date: Thu, 12 May 2011 18:27:21 +0200
[adding automake list in CC]

Recovering an oldish thread, as it seems we might be near to the
solution of this (only apparently simple) bug ...

For reference, see:
  <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7648>

On Wednesday 05 January 2011, Stefano Lattarini wrote:
> On Wednesday 05 January 2011, James Bostock wrote:
> > On Tue, Jan 4, 2011 at 11:36 PM, Stefano Lattarini wrote:
> > >
> > > JFTR, here is how that happens.  The ylwrap script works by doing a
> > > chdir into a temporary directory, calling yacc from there, renaming
> > > and editing the generated files, and then moving them back to the
> > > original directory.  In your case, since ylwrap knows nothing about
> > > the bison-generated 'stack.hh' and 'location.hh' header files, it
> > > doesn't copy them back in the original directory, so that they are
> > > lost when the temporary directory is removed.  D'oh!
> > >
> > > I'm still undecided if at this point we should just (try to) rewrite
> > > the messy ylwrap script, or if it would be better to teach automake
> > > to recognize when it's using bison as $(YACC), and take advantage of
> > > more bison features in this case -- which would probably allow to
> > > bypass the use of ylwrap altogether.
> > 
> > For what it's worth, I think the preferable solution would be to add
> > an AM_BISON macro to detect the presence of bison and, if it is
> > present, not use ylwrap at all as, unless in compatability mode,
> > bison's output files are named after the input grammar file anyway,
> > obviating the need for ylwrap.
> >
Well, not quite.  The ylwrap script has the nifty feature of avoiding to
update the timestamp of generated headers if their content hasn't changed
(to avoid unnecessary recompilation), while bison seems to update them
unconditionally.  I hadn't thought about this originally; luckily this
behaviour is covered by the testsuite, which saved me from introducing a
regression.

Also, the Makefile fragments generated by the Yacc support in Automake have
the ability to deal with the "deleted header problem" automatically for the
standard "y.tab.h" file.  It would be nice if they were able to do so also
for non-standard headers (with as small help from the developer as possible).

> Hmm... I agree, especially because most of the problems of ylwrap derive
> anyway from the use of bison-specific flags and features.
>
Now I don't agree with myself anymore :-)

I decided that, after all, the best thing to do was to rewrite the messy
ylwrap script; after some work, I've now reached a point where I think
we could safely add, without too much hassle, a new feature, that will
allow the developer to specify a list of extra headers generated by a
yacc call.

I'm not yet sure about the syntax to use for this new feature, though;
I was thinking about sometinh on the lines of:

  bin_PROGRAMS = zardoz
  zardoz_SOURCES = zardoz.yy
  zardoz_YFLAGS = -d --skeleton lalr1.cc
  EXTRA_zardoz_YACC_HEADERS = stack.hh location.hh position.hh

but I'd like to hear more ideas and opinions on this matter before
proceeding.

-*-*-

JFTR, the git branch where the work on the ylwrap rewrite is taking
place can be found here:

 <http://git.savannah.gnu.org/cgit/automake.git/log/?h=ylwrap-refactor>

-*-*-

Regards,
  Stefano




Information forwarded to owner <at> debbugs.gnu.org, bug-automake <at> gnu.org:
bug#7648; Package automake. (Thu, 28 Jul 2011 19:11:01 GMT) Full text and rfc822 format available.

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

From: Iain Nicol <iain <at> thenicols.net>
To: 7648 <at> debbugs.gnu.org
Subject: Re: Automake yacc support, GNU bison, and non-standard generated
	headers (was: Re: bug#7648: ylwrap appears not to support bison's
	lalr1.cc skeleton)
Date: Thu, 28 Jul 2011 19:08:36 +0100
Hi Stefano,

On 2011-05-12, Stefano Lattarini wrote:
> I decided that, after all, the best thing to do was to rewrite the
> messy ylwrap script; after some work, I've now reached a point where I
> think we could safely add, without too much hassle, a new feature,
> that will allow the developer to specify a list of extra headers
> generated by a yacc call.

> I'm not yet sure about the syntax to use for this new feature, though;
> I was thinking about sometinh on the lines of:

>  bin_PROGRAMS = zardoz
>  zardoz_SOURCES = zardoz.yy
>  zardoz_YFLAGS = -d --skeleton lalr1.cc
>  EXTRA_zardoz_YACC_HEADERS = stack.hh location.hh position.hh

> but I'd like to hear more ideas and opinions on this matter before
> proceeding.

Well, I'll give commenting a shot: that sounds pretty sensible to me.
But I must point out that I speak with limited Automake experience...

One thing which did strike me: EXTRA_ might not be the best prefix for
YACC_HEADERS.  If you do a ``make dist'' on a C Bison project then of
course zardoz.h is included in the dist tarball, which AFAICT is GNU
Coding Standards encouraged behaviour---presumably because installing
Bison used to be more difficult that it is these days.  It would be
consistent for the YACC_HEADERS to also end up also in the dist.

Then again, thinking about this some more, I'm probably worrying about
nothing, aren't I?  Based upon the patch attached to this bug, I gather
you can do wildcard matching.


Regards,
Iain




Information forwarded to owner <at> debbugs.gnu.org, bug-automake <at> gnu.org:
bug#7648; Package automake. (Fri, 05 Aug 2011 10:52:02 GMT) Full text and rfc822 format available.

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: bug-automake <at> gnu.org
Cc: 7648 <at> debbugs.gnu.org, Iain Nicol <iain <at> thenicols.net>
Subject: Re: bug#7648: Automake yacc support, GNU bison,
	and non-standard generated headers
Date: Fri, 5 Aug 2011 12:50:43 +0200
On Thursday 28 July 2011, Iain Nicol wrote:
> Hi Stefano,
>
Hi Iain, thanks for the answer (and sorry for the delay).

> On 2011-05-12, Stefano Lattarini wrote:
> > I decided that, after all, the best thing to do was to rewrite the
> > messy ylwrap script; after some work, I've now reached a point where I
> > think we could safely add, without too much hassle, a new feature,
> > that will allow the developer to specify a list of extra headers
> > generated by a yacc call.
> 
> > I'm not yet sure about the syntax to use for this new feature, though;
> > I was thinking about sometinh on the lines of:
> 
> >  bin_PROGRAMS = zardoz
> >  zardoz_SOURCES = zardoz.yy
> >  zardoz_YFLAGS = -d --skeleton lalr1.cc
> >  EXTRA_zardoz_YACC_HEADERS = stack.hh location.hh position.hh
> 
> > but I'd like to hear more ideas and opinions on this matter before
> > proceeding.
> 
> Well, I'll give commenting a shot: that sounds pretty sensible to me.
> But I must point out that I speak with limited Automake experience...
> 
> One thing which did strike me: EXTRA_ might not be the best prefix for
> YACC_HEADERS.  If you do a ``make dist'' on a C Bison project then of
> course zardoz.h is included in the dist tarball, which AFAICT is GNU
> Coding Standards encouraged behaviour---presumably because installing
> Bison used to be more difficult that it is these days.  It would be
> consistent for the YACC_HEADERS to also end up also in the dist.
>
I agree with what you say, but I don't see how this constitutes a
counter-argument to the use of EXTRA_ as a prefix for YACC_HEADERS.
Remember that EXTRA_ is not used only with EXTRA_DIST, but also
for things like EXTRA_PROGRAMS, that are obviously not meant to be
distributed.

Update: OTOH, quoting from the section "The Uniform Naming Scheme" of
the automake manual:

  For each primary, there is one additional variable named by prepending
  `EXTRA_' to the primary name. This variable is used to list objects
  that may or may not be built, depending on what configure decides.'

This doesn't fit very well with the situation we are talking about, so
`EXTRA_foo_YACC_HEADERS' is not a great name after all ...  Suggestions
on how to change it are welcome.

> Then again, thinking about this some more, I'm probably worrying about
> nothing, aren't I?
>
IMHO, no, you're not; consistency is important, and automake has already
its good share of ugly warts in this area, so that I'd rather avoid
adding new ones.

> Based upon the patch attached to this bug, I gather you can do wildcard
> matching.
>
Which patch are you referring to exactly?

> 
> Regards,
> Iain
 
Thanks,
  Stefano




Information forwarded to owner <at> debbugs.gnu.org, bug-automake <at> gnu.org:
bug#7648; Package automake. (Fri, 05 Aug 2011 10:52:02 GMT) Full text and rfc822 format available.

Information forwarded to owner <at> debbugs.gnu.org, bug-automake <at> gnu.org:
bug#7648; Package automake. (Tue, 09 Aug 2011 15:42:04 GMT) Full text and rfc822 format available.

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

From: Iain Nicol <iain <at> thenicols.net>
To: bug-automake <at> gnu.org
Cc: 7648 <at> debbugs.gnu.org, Stefano Lattarini <stefano.lattarini <at> gmail.com>
Subject: Re: bug#7648: Automake yacc support, GNU bison, and non-standard
	generated headers
Date: Tue, 9 Aug 2011 14:28:46 +0100
Hi,

Stefano Lattarini wrote:
> Hi Iain, thanks for the answer (and sorry for the delay).

No worries.  Plus, I also tend to delay.

> [Iain Nicol wrote:]
>> One thing which did strike me: EXTRA_ might not be the best prefix
>> for YACC_HEADERS.  If you do a ``make dist'' on a C Bison project
>> then of course zardoz.h is included in the dist tarball, which AFAICT
>> is GNU Coding Standards encouraged behaviour---presumably because
>> installing Bison used to be more difficult that it is these days.  It
>> would be consistent for the YACC_HEADERS to also end up also in the
>> dist.

> I agree with what you say, but I don't see how this constitutes a
> counter-argument to the use of EXTRA_ as a prefix for YACC_HEADERS.

It probably isn't a counter argument.  I'm thinking out loud, for better
or worse...

What I /was/ thinking is, because we may want these headers in the dist,
maybe the ``dist_'' prefix should be part of the variable name---at
least optionally.  I wasn't sure if there is an EXTRA_dist_
construction, which was what I was trying to get at before.

Either way, given that SOURCES is ``SOURCES'' and not ``dist_SOURCES'',
it's not clear that the name of YACC_HEADERS should have to have
``dist_'' in it--even if the files automatically end up in the dist.

On that note, /do/ you think the headers should end up in the dist
automatically, or do you think the user should have to do this:

  EXTRA_DIST += $(EXTRA_zardoz_YACC_HEADERS) ?

> Update: OTOH, quoting from the section "The Uniform Naming Scheme" of
> the automake manual:

>   For each primary, there is one additional variable named by
>   prepending `EXTRA_' to the primary name. This variable is used to
>   list objects that may or may not be built, depending on what
>   configure decides.'

> This doesn't fit very well with the situation we are talking about, so
> `EXTRA_foo_YACC_HEADERS' is not a great name after all ...
> Suggestions on how to change it are welcome.

I'll throw my only idea out there, with little idea of its suitability:
BUILT_ as a prefix, to make BUILT_YACC_HEADERS analogous to
BUILT_SOURCES.

But FWIW I can't see BUILT_ in the "Uniform Naming Scheme" manual
section.  And then the manual says this about BUILT_SOURCES:

  BUILT_SOURCES is actually a bit of a misnomer, as any file which must be
  created early in the build process can be listed in this variable.
  Moreover, all built sources do not necessarily have to be listed in
  BUILT_SOURCES.

So maybe not.

> Which patch are you referring to exactly?

I saw a patch attached to this bug, bug #7648.  (It's not a fix for the
main issue.)  I think it was committed here:

<http://git.savannah.gnu.org/cgit/automake.git/commit/?h=ylwrap-refactor&id=06efe9c467768a25c374b5d47dc8f1412874352d>

It's less the patch and more the log.  Before I read the log I hadn't
had obvious "aha" that Automake could be made to simultaneously match
either EXTRA_foo_YACC_HEADERS or EXTRA_foo_dist_YACC_HEADERS (or
whatever), well, if need be.  I really am thinking out loud, you see ;).


Regards,
Iain




Information forwarded to owner <at> debbugs.gnu.org, bug-automake <at> gnu.org:
bug#7648; Package automake. (Tue, 09 Aug 2011 15:42:04 GMT) Full text and rfc822 format available.

Information forwarded to bug-automake <at> gnu.org:
bug#7648; Package automake. (Sat, 14 Jul 2012 09:41:02 GMT) Full text and rfc822 format available.

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: bug-automake <at> gnu.org
Cc: 7648 <at> debbugs.gnu.org, James Bostock <james.bostock <at> gmail.com>,
	Iain Nicol <iain <at> thenicols.net>
Subject: Re: ylwrap appears not to support bison's lalr1.cc skeleton
Date: Sat, 14 Jul 2012 11:34:37 +0200
Reference: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7648>

The bug has finally been fixed by Akim Demaille (kudos to him); the fix
will appear in the next maintenance version of Automake (1.12.3).

See the thread:
  <http://lists.gnu.org/archive/html/automake-patches/2012-07/msg00088.html>
and in particular the messages:
  <http://lists.gnu.org/archive/html/automake-patches/2012-07/msg00123.html>
  <http://lists.gnu.org/archive/html/automake-patches/2012-07/msg00139.html>

I will proceed to close this bug report once those patches are actually
merged into maint.

Regards,
  Stefano




Reply sent to Stefano Lattarini <stefano.lattarini <at> gmail.com>:
You have taken responsibility. (Mon, 16 Jul 2012 09:24:01 GMT) Full text and rfc822 format available.

Notification sent to James Bostock <james.bostock <at> gmail.com>:
bug acknowledged by developer. (Mon, 16 Jul 2012 09:24:03 GMT) Full text and rfc822 format available.

Message #49 received at 7648-done <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: 7648-done <at> debbugs.gnu.org
Cc: james.bostock <at> gmail.com, iain <at> thenicols.net
Subject: Re: bug#7648: ylwrap appears not to support bison's lalr1.cc skeleton
Date: Mon, 16 Jul 2012 11:17:49 +0200
On 07/14/2012 11:34 AM, Stefano Lattarini wrote:
> Reference: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7648>
> 
> The bug has finally been fixed by Akim Demaille (kudos to him); the fix
> will appear in the next maintenance version of Automake (1.12.3).
> 
> See the thread:
>   <http://lists.gnu.org/archive/html/automake-patches/2012-07/msg00088.html>
> and in particular the messages:
>   <http://lists.gnu.org/archive/html/automake-patches/2012-07/msg00123.html>
>   <http://lists.gnu.org/archive/html/automake-patches/2012-07/msg00139.html>
> 
> I will proceed to close this bug report once those patches are actually
> merged into maint.
>
Done.  I'm thus closing this bug report.

Thanks,
  Stefano




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Mon, 13 Aug 2012 11:24:03 GMT) Full text and rfc822 format available.

This bug report was last modified 11 years and 230 days ago.

Previous Next


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