From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 15 13:44:04 2010 Received: (at submit) by debbugs.gnu.org; 15 Dec 2010 18:44:04 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PSwKZ-0006EJ-Rd for submit@debbugs.gnu.org; Wed, 15 Dec 2010 13:44:04 -0500 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PSw2K-0005nv-VP for submit@debbugs.gnu.org; Wed, 15 Dec 2010 13:25:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PSw8P-0001dQ-58 for submit@debbugs.gnu.org; Wed, 15 Dec 2010 13:31:29 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, T_DKIM_INVALID, T_TO_NO_BRKTS_FREEMAIL autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([199.232.76.165]:34942) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PSw7j-0007qL-4H for submit@debbugs.gnu.org; Wed, 15 Dec 2010 13:31:29 -0500 Received: from [140.186.70.92] (port=59363 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PSw4V-0007YY-7o for bug-automake@gnu.org; Wed, 15 Dec 2010 13:27:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PSw4O-0000kk-Jp for bug-automake@gnu.org; Wed, 15 Dec 2010 13:27:22 -0500 Received: from mail-qw0-f41.google.com ([209.85.216.41]:51506) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PSw4O-0000kW-GL for bug-automake@gnu.org; Wed, 15 Dec 2010 13:27:20 -0500 Received: by qwa26 with SMTP id 26so2201458qwa.0 for ; Wed, 15 Dec 2010 10:27:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=sS4zAkScUNopBExYtCM5TnnFoLG9tEZfh4dsHxjByB0=; b=fyZkOVt0J2+2xm140yuvHj6mqcBXbBEIxjrR90ARtAPHdq9iyKAtBedU95PP1bkpRE L+RiPQMkBmWv1deKf9PWszH/9CUZB5L/Us5fdR8mUMHhVUu6Yx3D8jUdPpJGbHCrdk76 +SIDqZzlv8Axnm/kPMl81RlNkEZwuSdKKdBTw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=UxlDbsBclC/gb9ehXSw2g2wTpxd/aAvMPfdxkYMgEecnRRL76wK8ah3vvYF2anIk2I 3hxqX99dCwdt6hlokrqsgTfhd6zPMjxkBhABdW2PtT2Yswf+hQNl8G45i1PPh1m78bIf g8T/YoPnEppweW85NtrBBDKzmC5bb5bH1Slic= MIME-Version: 1.0 Received: by 10.224.28.77 with SMTP id l13mr6567904qac.301.1292437639190; Wed, 15 Dec 2010 10:27:19 -0800 (PST) Received: by 10.220.181.137 with HTTP; Wed, 15 Dec 2010 10:27:19 -0800 (PST) Date: Wed, 15 Dec 2010 19:27:19 +0100 Message-ID: Subject: ylwrap appears not to support bison's lalr1.cc skeleton From: James Bostock To: bug-automake@gnu.org Content-Type: multipart/mixed; boundary=0015175caa2460dae204977716be X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Spam-Score: -5.9 (-----) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Wed, 15 Dec 2010 13:44:02 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.9 (-----) --0015175caa2460dae204977716be Content-Type: text/plain; charset=ISO-8859-1 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 --0015175caa2460dae204977716be Content-Type: application/octet-stream; name="bisonpp.test" Content-Disposition: attachment; filename="bisonpp.test" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ghqjl01g0 IyEgL2Jpbi9zaAojIENvcHlyaWdodCAoQykgMTk5NywgMjAwMSwgMjAwMiwgMjAwNiAgRnJlZSBT b2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCiMKIyBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2Fy ZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQojIGl0IHVuZGVyIHRoZSB0 ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5CiMg dGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMiwgb3IgKGF0IHlv dXIgb3B0aW9uKQojIGFueSBsYXRlciB2ZXJzaW9uLgojCiMgVGhpcyBwcm9ncmFtIGlzIGRpc3Ry aWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCiMgYnV0IFdJVEhPVVQg QU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKIyBNRVJD SEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhl CiMgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KIwojIFlvdSBz aG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNl bnNlCiMgYWxvbmcgd2l0aCB0aGlzIHByb2dyYW0uICBJZiBub3QsIHNlZSA8aHR0cDovL3d3dy5n bnUub3JnL2xpY2Vuc2VzLz4uCgojIFRlc3QgdG8gbWFrZSBzdXJlIGJpc29uICsgYmlzb24ncyBD Kysgc2tlbGV0b24gKyBDKysgd29ya3MuCgpyZXF1aXJlZD0iYmlzb24gZ2NjIgoKLiAuL2RlZnMg fHwgRXhpdCAxCgpzZXQgLWUKCmNhdCA+IGNvbmZpZ3VyZS5pbiA8PCAnRU5EJwpBQ19JTklUKFt5 YWNjcHAyXSwgWzEuMF0pCkFDX0NPTkZJR19BVVhfRElSKFsuXSkKQU1fSU5JVF9BVVRPTUFLRQpB Q19DT05GSUdfRklMRVMoW01ha2VmaWxlXSkKQUNfUFJPR19DWFgKQUNfUFJPR19ZQUNDCkFDX09V VFBVVApFTkQKCmNhdCA+IE1ha2VmaWxlLmFtIDw8ICdFTkQnCmJpbl9QUk9HUkFNUyA9IHphcmRv egp6YXJkb3pfU09VUkNFUyA9IHphcmRvei55eSBmb28uY2MKQU1fWUZMQUdTID0gLWQgLS1za2Vs ZXRvbiBsYWxyMS5jYwpFTkQKCiMgUGFyc2VyLgpjYXQgPiB6YXJkb3oueXkgPDwgJ0VORCcKJXsK aW50IHl5bGV4ICgpIHtyZXR1cm4gMDt9CnZvaWQgeXllcnJvciAoY2hhciAqcykge30KJX0KJSUK Zm9vYmFyIDogJ2YnICdvJyAnbycgJ2InICdhJyAncicge307CkVORAoKY2F0ID4gZm9vLmNjIDw8 ICdFTkQnCmludCBtYWluKGludCBhcmdjLCBjaGFyKiogYXJndikgeyByZXR1cm4gMDsgfQpFTkQK CiRBQ0xPQ0FMCiRBVVRPQ09ORgokQVVUT01BS0UgLWEKCm1rZGlyIHN1YgpjZCBzdWIKCi4uL2Nv bmZpZ3VyZQokTUFLRQo= --0015175caa2460dae204977716be-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 04 17:29:10 2011 Received: (at 7648) by debbugs.gnu.org; 4 Jan 2011 22:29:10 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PaFNN-0007PR-On for submit@debbugs.gnu.org; Tue, 04 Jan 2011 17:29:10 -0500 Received: from mail-ww0-f42.google.com ([74.125.82.42]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PaFNM-0007PF-Jj for 7648@debbugs.gnu.org; Tue, 04 Jan 2011 17:29:09 -0500 Received: by wwi17 with SMTP id 17so15903396wwi.3 for <7648@debbugs.gnu.org>; Tue, 04 Jan 2011 14:36:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=+TauGYgIfi57v1eZswEiyWtO1P7CG3HA3FCYppFHdmM=; b=O/zJJYPR2QvH1DmmonNomcWZtUa475w6fqYRKY5X44y/2eIOCQSjTXnWVHP/pvjkKG g4u2xYO5yWjfdPfmjnJ3fL73KB0uZ9sLHR/V8FLQv6PIXoSot1QQNtuXMfli7a6SA8w5 ouwAfy79Nue1Tg4lVw6MRkhg+g3KsOUz3llOE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=fdDuwpp6fwi5E+JIsT7wu2A6si0v+lUJztSEsW4QzN2khTd8geApiR8HNBdX1M/ISG qvXE8dYr6hQeT1D3W10GQtPxecbGw2X1MIjruzFkDgI+IvrY5GGsHZfaaLtIb9lh7oz+ bmCcat2A+q4OcUnH+ZWKhlW37RYbKSbCF8tx8= Received: by 10.216.186.208 with SMTP id w58mr1152126wem.59.1294180578144; Tue, 04 Jan 2011 14:36:18 -0800 (PST) Received: from bigio.localnet (host7-53-dynamic.48-82-r.retail.telecomitalia.it [82.48.53.7]) by mx.google.com with ESMTPS id 7sm10831268wet.24.2011.01.04.14.36.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 04 Jan 2011 14:36:17 -0800 (PST) From: Stefano Lattarini To: James Bostock Subject: Re: bug#7648: ylwrap appears not to support bison's lalr1.cc skeleton Date: Tue, 4 Jan 2011 23:36:05 +0100 User-Agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201101042336.06326.stefano.lattarini@gmail.com> X-Spam-Score: -3.6 (---) X-Debbugs-Envelope-To: 7648 Cc: 7648@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) 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 From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 05 06:11:29 2011 Received: (at 7648) by debbugs.gnu.org; 5 Jan 2011 11:11:29 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PaRH7-0006Vy-CG for submit@debbugs.gnu.org; Wed, 05 Jan 2011 06:11:29 -0500 Received: from mail-qw0-f44.google.com ([209.85.216.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PaRH6-0006Vk-3S for 7648@debbugs.gnu.org; Wed, 05 Jan 2011 06:11:28 -0500 Received: by qwg5 with SMTP id 5so15176497qwg.3 for <7648@debbugs.gnu.org>; Wed, 05 Jan 2011 03:18:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=aucyZ5DTjGHvmdLUvGPXlvtHGMYDxcyjQzTbcv31qC8=; b=iTclirHQK2yXrRc1OL3nzN8YKJWNfLIhHbhD8WBfZZZ5PEIeFrmhANYWwAAd54Jhze gMs6OMjbK9QYBK7qB/EE/0CHem22y9//PvJJVMGpCJIqA8MgcGP3ClOlxiiuKwEL89w1 5n/bAqE6D7a0vLnu++XozFWpjn2z6IsOFjfTo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Pzs6KmeWLqGbDwTMW8q3kHoh/DRJRb7eUK0gCnsS/gfG2VlDTaEpCHw//uptlX3CMq YpkWcxEvflatE6OVIivTltcdyzBvfRQykoTXhljkzSkY2rBp+cQmn7UlQZyirN7/sGhR VP1ZCBoCGjpOcU4zSlxx4e096emwFQrcvMfr8= MIME-Version: 1.0 Received: by 10.224.60.213 with SMTP id q21mr20950647qah.351.1294226319301; Wed, 05 Jan 2011 03:18:39 -0800 (PST) Received: by 10.220.202.73 with HTTP; Wed, 5 Jan 2011 03:18:39 -0800 (PST) In-Reply-To: <201101042336.06326.stefano.lattarini@gmail.com> References: <201101042336.06326.stefano.lattarini@gmail.com> Date: Wed, 5 Jan 2011 12:18:39 +0100 Message-ID: Subject: Re: bug#7648: ylwrap appears not to support bison's lalr1.cc skeleton From: James Bostock To: Stefano Lattarini Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -4.8 (----) X-Debbugs-Envelope-To: 7648 Cc: 7648@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.4 (----) 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 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 From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 05 14:25:27 2011 Received: (at 7648) by debbugs.gnu.org; 5 Jan 2011 19:25:27 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PaYz9-0001ga-Dx for submit@debbugs.gnu.org; Wed, 05 Jan 2011 14:25:27 -0500 Received: from mail-ww0-f46.google.com ([74.125.82.46]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PaYz7-0001gN-P3 for 7648@debbugs.gnu.org; Wed, 05 Jan 2011 14:25:26 -0500 Received: by wwj40 with SMTP id 40so17270369wwj.15 for <7648@debbugs.gnu.org>; Wed, 05 Jan 2011 11:32:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=bDJ/HluMCoYizx6CgNp2LtyU8sxnRwruWkrG0CAZHGA=; b=s5DLQ259xQrzTtGf99AcxPg1bNbZp8M8UHVOmZmRD8KuqEDM2iXoz7713iW0zz43Fi 2ICPUCs7ue654rr9/kLX2aZr+djeORkvyilezyoQbOt8OBpQu1BV2fVmqApcuvyTxIaz 6QWvHxYgPyLqDKpBqoxNSyVI6elIKWxAriR2Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=TP4loUESAWwlkg+nQFxiJi4PXiLPpSY9/LSZgK2KcA9hU9EOzPxC7c1yDRGGWlgsdZ TVzKmqJF/UzULh4OeQMK0xr3eHGmtsDhmGmMP49qcOQ91STzhVqtr07qaXynI4BE6e3Z eltSvrZ7BJZVX/k8sn/XCTFDNXqHMRBGkRhH8= Received: by 10.216.162.84 with SMTP id x62mr22727741wek.106.1294255957481; Wed, 05 Jan 2011 11:32:37 -0800 (PST) Received: from bigio.localnet (host126-166-dynamic.50-82-r.retail.telecomitalia.it [82.50.166.126]) by mx.google.com with ESMTPS id t5sm11361815wes.9.2011.01.05.11.32.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 05 Jan 2011 11:32:36 -0800 (PST) From: Stefano Lattarini To: James Bostock Subject: Re: bug#7648: ylwrap appears not to support bison's lalr1.cc skeleton Date: Wed, 5 Jan 2011 20:32:10 +0100 User-Agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; ) References: <201101042336.06326.stefano.lattarini@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201101052032.10845.stefano.lattarini@gmail.com> X-Spam-Score: -4.5 (----) X-Debbugs-Envelope-To: 7648 Cc: 7648@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.4 (----) 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 > 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 18 08:22:05 2011 Received: (at 7648) by debbugs.gnu.org; 18 Jan 2011 13:22:06 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PfBVc-0006hE-T1 for submit@debbugs.gnu.org; Tue, 18 Jan 2011 08:22:05 -0500 Received: from mail-ww0-f46.google.com ([74.125.82.46]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PfBVb-0006gm-G4 for 7648@debbugs.gnu.org; Tue, 18 Jan 2011 08:22:04 -0500 Received: by wwj40 with SMTP id 40so6576237wwj.15 for <7648@debbugs.gnu.org>; Tue, 18 Jan 2011 05:29:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=3BW0yLwB47nfCLA28coLNI/lrTAzk4s70oMT8gJVu/Y=; b=lxLTlHcpuvh6cHK9+V/89P7uBUDiL5YFvxsbUmr9jABy0nl2wjZk3Qr2I7hpP9AFMj RNdV0YBxo5N5uZMIUarAzUuv7u3FRwvj+my6pyaZWGJo6SwQ8VEj2jrTIHAEYkVbs6No eBD/iQJ7wsfYaoGMS9hBk63xnKK8mRfVw5YpU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=oeCP9OmlCqr9zDLPSnj3yoY38HLi5hQ8zK28M5R1OupPV/c0/SPOmIu1GBdaJVMOm9 RgjnkmxAAPNfNHdFg7WmIMleUlONggQnfLUZxUQbH1Rmpf3wXusV1RwzRxbmXF2fiBrd gikJYmm3ZARXppq1Pg6uwS8/rW8w9nH4bdo+0= Received: by 10.216.82.68 with SMTP id n46mr4331790wee.90.1295357387313; Tue, 18 Jan 2011 05:29:47 -0800 (PST) Received: from bigio.localnet (host121-110-dynamic.55-82-r.retail.telecomitalia.it [82.55.110.121]) by mx.google.com with ESMTPS id o33sm2982390wej.13.2011.01.18.05.29.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 18 Jan 2011 05:29:45 -0800 (PST) From: Stefano Lattarini To: James Bostock Subject: Re: bug#7648: ylwrap appears not to support bison's lalr1.cc skeleton Date: Tue, 18 Jan 2011 14:29:24 +0100 User-Agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; ) References: <201101052032.10845.stefano.lattarini@gmail.com> In-Reply-To: <201101052032.10845.stefano.lattarini@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201101181429.25230.stefano.lattarini@gmail.com> X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: 7648 Cc: 7648@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) 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!): 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 28 07:58:33 2011 Received: (at 7648) by debbugs.gnu.org; 28 Jan 2011 12:58:33 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PinuK-0003bq-1g for submit@debbugs.gnu.org; Fri, 28 Jan 2011 07:58:33 -0500 Received: from mail-ww0-f46.google.com ([74.125.82.46]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PinuF-0003ba-W3 for 7648@debbugs.gnu.org; Fri, 28 Jan 2011 07:58:29 -0500 Received: by wwj40 with SMTP id 40so3397010wwj.15 for <7648@debbugs.gnu.org>; Fri, 28 Jan 2011 05:06:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:subject:date:user-agent:cc:mime-version :content-type:message-id; bh=x59n65IL6kZuOeGwHIDQYjyaSGVko/JXDJFFS34pXoQ=; b=nYiiZrxkbgkWj5N/ZDXkRxyS30DvZ0llDQv5eFnJEq4DogJd2tTKvai8B/vWYXLyAI OKpQs8MrxrysNIu/0WJsckNIaCVTyTDAvXptforEOPHLeoMVhrnLoTiYin8MhPf9FeF/ TFtVpE5ziEvqcKN3vQEcqYYrRUui2LfnzYTEc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:mime-version:content-type :message-id; b=t5AbVZrergmfwQYjDHIS/SQKQGkbc1LcKC149C3uOUjwtSjZI2X4XjVBRDqi+MkABS c8CZXgQyt/hQBqYWcvroQclXNTSXzmsLixEdzwwtR40caakYtj11eE/H6ptD+d/tb/4x uLzgp9bkmjRYkOx2AqE8HqjQ30swDBgRzabik= Received: by 10.216.19.207 with SMTP id n57mr3505715wen.30.1296219999798; Fri, 28 Jan 2011 05:06:39 -0800 (PST) Received: from bigio.localnet (host124-38-dynamic.52-82-r.retail.telecomitalia.it [82.52.38.124]) by mx.google.com with ESMTPS id c54sm9022142wer.30.2011.01.28.05.06.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 28 Jan 2011 05:06:38 -0800 (PST) From: Stefano Lattarini To: automake-patches@gnu.org Subject: [PATCH] {yacc-work} yacc: extension of headers modelled after extension of sources Date: Fri, 28 Jan 2011 14:06:23 +0100 User-Agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; ) MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_Q9rQN7bqOCo2WfE" Message-Id: <201101281406.24302.stefano.lattarini@gmail.com> X-Spam-Score: -3.8 (---) X-Debbugs-Envelope-To: 7648 Cc: 7648@debbugs.gnu.org, James Bostock X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.8 (---) --Boundary-00=_Q9rQN7bqOCo2WfE Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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. --Boundary-00=_Q9rQN7bqOCo2WfE Content-Type: text/x-patch; charset="us-ascii"; name="0001-yacc-extension-of-headers-modelled-after-extension-o.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="0001-yacc-extension-of-headers-modelled-after-extension-o.patch" =46rom e3d6064f7faf582d70871bed40a9d19c9d4c98d4 Mon Sep 17 00:00:00 2001 =46rom: Stefano Lattarini Date: Fri, 21 Jan 2011 17:47:42 +0100 Subject: [PATCH] yacc: extension of headers modelled after extension of sou= rces 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. =2D-- 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 =2D-- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,27 @@ +2011-01-28 Stefano Lattarini + + 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 =20 docs: clustered '-d' not recognized in YFLAGS diff --git a/automake.in b/automake.in index fa458d6..e2e67b9 100755 =2D-- a/automake.in +++ b/automake.in @@ -6084,12 +6084,26 @@ sub lang_yacc_target_hook =20 if ($yflags_contains_minus_d) { =2D (my $output_base =3D $output) =3D~ s/$KNOWN_EXTENSIONS_PATTERN$//; =2D my $header =3D $output_base . '.h'; =2D # 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 =3D basename ($output)) =3D~ 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 =3D $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 =3D $output_ext) =3D~ 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 =3D $output) =3D~ 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 =2D-- 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. =2Dif %?MAINTAINER-MODE% if %?FIRST% +if %?MAINTAINER-MODE% @MAINTAINER_MODE_FALSE@am__skipyacc =3D test -f $@ || =2Dendif %?FIRST% endif %?MAINTAINER-MODE% +## The 's/c$/h/' substitution *must* be the last one. +am__yacc_c2h =3D sed -e s/cc$$/hh/ -e s/cpp$$/hpp/ -e s/cxx$$/hxx/ \ + -e s/c++$$/h++/ -e s/c$$/h/ +endif %?FIRST% =20 ?GENERIC?%EXT%%DERIVED-EXT%: ?!GENERIC?%OBJ%: %SOURCE% =2D?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 %OB= J% y.tab.h `echo %OBJ% | $(am__yacc_c2h)` y.output %BASE%.output -- %COMPIL= E% ?!GENERIC? %VERBOSE% \ ?!GENERIC??DIST_SOURCE? $(am__skipyacc) \ ## For non-suffix rules, we must emulate a VPATH search on %SOURCE%. =2D?!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)/'`%SO= URCE% 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 =2D-- 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 =2D-- 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 =2D-- 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 . =20 =2D# 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'. =20 required=3Dyacc . ./defs || Exit 1 diff --git a/tests/yacc-cxx.test b/tests/yacc-cxx.test new file mode 100755 index 0000000..86693d6 =2D-- /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 . + +# Basic semantic checks on Yacc + C++ support (when yacc-generated +# headers are not involved). +# Keep in sync with sister test `yacc-basic.test'. + +required=3Dyacc +. ./defs || Exit 1 + +distdir=3D$me-1.0 + +cat >> configure.in << 'END' +AC_PROG_CXX +AC_PROG_YACC +AC_OUTPUT +END + +cat > Makefile.am << 'END' +bin_PROGRAMS =3D foo1 foo2 foo3 foo4 +foo1_SOURCES =3D parse1.yy foo.cc +foo2_SOURCES =3D parse2.y++ bar.c++ +foo3_SOURCES =3D parse3.yxx foo.cc +foo4_SOURCES =3D parse4.ypp bar.cxx +foo3_YFLAGS =3D -v +foo4_YFLAGS =3D $(foo3_YFLAGS) + +.PHONY: echo-distcom +echo-distcom: + @echo ' ' $(DIST_COMMON) ' ' +END + +cat > parse1.yy << 'END' +%{ +// Valid as C++, but deliberatly invalid as C. +#include +#include +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 =2D-- 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 . =20 =2D# Tests on basic Yacc support for when we have -d in YFLAGS, AM_YFLAGS =2D# 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'. =20 required=3Dyacc . ./defs || Exit 1 @@ -111,7 +112,7 @@ test -f bar/parse.h test -f baz/zardoz-parse.c test -f baz/zardoz-parse.h =20 =2D# 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 =2D-- /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 . + +# 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=3Dyacc +. ./defs || Exit 1 + +set -e + +tab=3D' ' +distdir=3D$me-1.0 + +write_parse () +{ + header=3D$1 + sed 's/^ *//' < + #include "$header" + int yylex (void) { return 0; } + void yyerror (const char *s) {} + %} + %% + x : 'x' {}; + %% +END +} + +write_main () +{ + header=3D$1 + sed 's/^ *//' < + #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 =3D 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 < foo/parse.yy +write_main parse.hh > foo/main.cc + +# Try with -d in $(AM_YFLAGS). +cat >> bar/Makefile.am < bar/parse.ypp +write_main parse.hpp > bar/main.cpp + +# Try with -d in $(AM_YFLAGS), and a subdir parser. +cat >> baz/Makefile.am < 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 < 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 =2D-- /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 . + +# 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 =3D foo bar foo2 bar2 + +foo_SOURCES =3D parse.y.y +bar_SOURCES =3D parse.s.f..y +bar_YFLAGS =3D -d + +foo2_SOURCES =3D parse..5.y++ +bar2_SOURCES =3D parse.yxx.yy +bar2_YFLAGS =3D -d +END + +outputs=3D' 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 =2D-- 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 . =20 =2D# Test to make sure Yacc + C++ is supported. =2D# 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). =20 . ./defs || Exit 1 =20 @@ -38,10 +40,45 @@ END $ACLOCAL $AUTOMAKE -a =20 +$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 =20 +cat >> Makefile.am <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 + : =2D-=20 1.7.2.3 --Boundary-00=_Q9rQN7bqOCo2WfE-- From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 10 04:26:59 2011 Received: (at 7648) by debbugs.gnu.org; 10 Apr 2011 08:27:00 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q8pz1-00051R-Ey for submit@debbugs.gnu.org; Sun, 10 Apr 2011 04:26:59 -0400 Received: from mail-ww0-f46.google.com ([74.125.82.46]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q8pyy-00051E-Ox for 7648@debbugs.gnu.org; Sun, 10 Apr 2011 04:26:57 -0400 Received: by wwb28 with SMTP id 28so5884958wwb.15 for <7648@debbugs.gnu.org>; Sun, 10 Apr 2011 01:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=NQwPqvJLKjfk4GLITNh2MAbXmWdxvDy8oYZ/z23msIk=; b=t8RD2S2QMeSE9i6xEAtGX7uSYnS2vBMO04+TXbZLn8HZWY5xWYM5us9dm7hGgRkQeY vtaTA5lcJv+M01UH8gusju0KRcZnrK1timiG8zTVIjUiflopc6BJuvctPQayuS9Bzl8N V17WucqvP+96Hf/Lrspkoo/BogpG+Dk2/yDqQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=BYiAYMwQWSifrhnBIQnAZcNiaBtld47cKT7T8kyj/AqMkqb8jsKNk/vnoLuDs0zZ7W 5ZgiUesiHGPh45xZ6kZTbSegpXBRBpmpWEr8WtJFR4uduOaxzT+2cKdS+FecygA7IGe+ S2yc8zs2ZrNVyG0nd3inhFw2a2+/4nQB/8FMs= Received: by 10.216.167.65 with SMTP id h43mr1488043wel.17.1302424010671; Sun, 10 Apr 2011 01:26:50 -0700 (PDT) Received: from bigio.localnet (host162-95-dynamic.0-87-r.retail.telecomitalia.it [87.0.95.162]) by mx.google.com with ESMTPS id r80sm2084682wei.15.2011.04.10.01.26.49 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 10 Apr 2011 01:26:49 -0700 (PDT) From: Stefano Lattarini To: automake-patches@gnu.org 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 User-Agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; ) References: <201101281406.24302.stefano.lattarini@gmail.com> In-Reply-To: <201101281406.24302.stefano.lattarini@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201104101026.41362.stefano.lattarini@gmail.com> X-Spam-Score: -3.9 (---) X-Debbugs-Envelope-To: 7648 Cc: 7648@debbugs.gnu.org, James Bostock X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.9 (---) Reference: 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 From debbugs-submit-bounces@debbugs.gnu.org Thu May 12 12:27:42 2011 Received: (at 7648) by debbugs.gnu.org; 12 May 2011 16:27:42 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QKYjm-0006cJ-B8 for submit@debbugs.gnu.org; Thu, 12 May 2011 12:27:42 -0400 Received: from mail-ww0-f46.google.com ([74.125.82.46]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QKYjj-0006c6-QP for 7648@debbugs.gnu.org; Thu, 12 May 2011 12:27:40 -0400 Received: by wwb28 with SMTP id 28so1894052wwb.15 for <7648@debbugs.gnu.org>; Thu, 12 May 2011 09:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:message-id:content-type :content-transfer-encoding; bh=tdEO58KKzjlrZtDx0L2SFTbR5ORN/i7gbih9j6Av1Eg=; b=ncS/itIiQdnaPWEtlal9YYAY7GXaNiNPpnrjovPVorAo8SfxzYCn9lqSEl11XMVbk6 zobsYzTLxWaAK709hyk/I9VdizLqQz6BePL+YbjCaKUwFKgEJab6LPUetc4A4vSEZPuC uojLXbZdv/t7HzHl8XY/MLIh+WHrn94IJN6kU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:message-id:content-type:content-transfer-encoding; b=UQsFlrxQHt9Sl6ogFDhsvkSa3qtYBpOZMSjzHRJ7Lu8ai/cJMQI4Pv/LIMuRDBPHhe KvEkIlwzx8hVZ51Jmg0wtoJpr4Ab2lqhhN6FYtPkMjLwqxP7hvu+k1s+62NBJu4M5I8y ej5ltLf00dXVE+CERqabW4CdFv3BWfIOf9v38= Received: by 10.227.198.80 with SMTP id en16mr435343wbb.58.1305217653790; Thu, 12 May 2011 09:27:33 -0700 (PDT) Received: from bigio.localnet (host211-99-dynamic.5-87-r.retail.telecomitalia.it [87.5.99.211]) by mx.google.com with ESMTPS id y29sm841330wbd.38.2011.05.12.09.27.31 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 May 2011 09:27:32 -0700 (PDT) From: Stefano Lattarini To: James Bostock 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 User-Agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; ) References: <201101052032.10845.stefano.lattarini@gmail.com> In-Reply-To: <201101052032.10845.stefano.lattarini@gmail.com> MIME-Version: 1.0 Message-Id: <201105121827.22528.stefano.lattarini@gmail.com> Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Spam-Score: -3.6 (---) X-Debbugs-Envelope-To: 7648 Cc: 7648@debbugs.gnu.org, automake@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) [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: 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: -*-*- Regards, Stefano From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 28 15:10:25 2011 Received: (at 7648) by debbugs.gnu.org; 28 Jul 2011 19:10:25 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QmVyS-00065E-7b for submit@debbugs.gnu.org; Thu, 28 Jul 2011 15:10:25 -0400 Received: from mail-vw0-f43.google.com ([209.85.212.43]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QmV0g-00023U-GC for 7648@debbugs.gnu.org; Thu, 28 Jul 2011 14:08:39 -0400 Received: by vws10 with SMTP id 10so2833905vws.30 for <7648@debbugs.gnu.org>; Thu, 28 Jul 2011 11:08:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.198.194 with SMTP id ep2mr80460vcb.233.1311876517182; Thu, 28 Jul 2011 11:08:37 -0700 (PDT) Received: by 10.220.100.17 with HTTP; Thu, 28 Jul 2011 11:08:36 -0700 (PDT) X-Originating-IP: [81.6.245.94] Date: Thu, 28 Jul 2011 19:08:36 +0100 Message-ID: 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) From: Iain Nicol To: 7648@debbugs.gnu.org Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -3.6 (---) X-Debbugs-Envelope-To: 7648 X-Mailman-Approved-At: Thu, 28 Jul 2011 15:10:22 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 05 06:51:55 2011 Received: (at submit) by debbugs.gnu.org; 5 Aug 2011 10:51:55 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QpI0Q-00012O-ES for submit@debbugs.gnu.org; Fri, 05 Aug 2011 06:51:54 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QpI0N-000129-VZ for submit@debbugs.gnu.org; Fri, 05 Aug 2011 06:51:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QpHzc-0000Fn-Lx for submit@debbugs.gnu.org; Fri, 05 Aug 2011 06:51:07 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, T_DKIM_INVALID, T_TO_NO_BRKTS_FREEMAIL autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:46277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QpHzc-0000Fj-KO for submit@debbugs.gnu.org; Fri, 05 Aug 2011 06:51:04 -0400 Received: from eggs.gnu.org ([140.186.70.92]:47976) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QpHzY-0005q8-Jx for bug-automake@gnu.org; Fri, 05 Aug 2011 06:51:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QpHzU-0000F5-Hq for bug-automake@gnu.org; Fri, 05 Aug 2011 06:51:00 -0400 Received: from mail-wy0-f169.google.com ([74.125.82.169]:54390) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QpHzU-0000El-BV for bug-automake@gnu.org; Fri, 05 Aug 2011 06:50:56 -0400 Received: by wyg36 with SMTP id 36so2286891wyg.0 for ; Fri, 05 Aug 2011 03:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=2XjbNc8sa1EeCnxHl+3sscO/ul0mCsml0Tux9bYKWUw=; b=IP5wDNqVs1B2m85x1wSgziN8oWvgWZeyfdRK5HFsCysq5pvBS4vy9TbVcefWyhaMb/ zXx95mbSTZmnJtQ5vZJcAGOgXz4Ttm715CGd9icoSQE3iJAWyVoa465S1IPBy5mcg3QJ G6Aomk659CgdhwH9JCtz37Le7rwK3bhogDDow= Received: by 10.216.16.79 with SMTP id g57mr1641606weg.74.1312541455189; Fri, 05 Aug 2011 03:50:55 -0700 (PDT) Received: from bigio.localnet (host78-93-dynamic.7-79-r.retail.telecomitalia.it [79.7.93.78]) by mx.google.com with ESMTPS id h13sm285533wee.10.2011.08.05.03.50.53 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Aug 2011 03:50:54 -0700 (PDT) From: Stefano Lattarini To: bug-automake@gnu.org Subject: Re: bug#7648: Automake yacc support, GNU bison, and non-standard generated headers Date: Fri, 5 Aug 2011 12:50:43 +0200 User-Agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201108051250.44377.stefano.lattarini@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -5.1 (-----) X-Debbugs-Envelope-To: submit Cc: 7648@debbugs.gnu.org, Iain Nicol X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.1 (-----) 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 09 11:41:31 2011 Received: (at submit) by debbugs.gnu.org; 9 Aug 2011 15:41:31 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QqoQs-00011e-Ll for submit@debbugs.gnu.org; Tue, 09 Aug 2011 11:41:31 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QqmNu-00062h-J2 for submit@debbugs.gnu.org; Tue, 09 Aug 2011 09:30:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QqmMd-000531-Nr for submit@debbugs.gnu.org; Tue, 09 Aug 2011 09:29:11 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:60904) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqmMd-00052g-Ix for submit@debbugs.gnu.org; Tue, 09 Aug 2011 09:28:59 -0400 Received: from eggs.gnu.org ([140.186.70.92]:40830) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqmMY-0003ij-9A for bug-automake@gnu.org; Tue, 09 Aug 2011 09:28:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QqmMT-0004m6-SD for bug-automake@gnu.org; Tue, 09 Aug 2011 09:28:54 -0400 Received: from mail-vw0-f41.google.com ([209.85.212.41]:51032) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqmMT-0004ka-Al for bug-automake@gnu.org; Tue, 09 Aug 2011 09:28:49 -0400 Received: by vwm42 with SMTP id 42so4042306vwm.0 for ; Tue, 09 Aug 2011 06:28:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.99.42 with SMTP id en10mr1994407vdb.220.1312896526702; Tue, 09 Aug 2011 06:28:46 -0700 (PDT) Received: by 10.220.95.209 with HTTP; Tue, 9 Aug 2011 06:28:46 -0700 (PDT) X-Originating-IP: [195.11.9.82] In-Reply-To: <201108051250.44377.stefano.lattarini@gmail.com> References: <201108051250.44377.stefano.lattarini@gmail.com> Date: Tue, 9 Aug 2011 14:28:46 +0100 Message-ID: Subject: Re: bug#7648: Automake yacc support, GNU bison, and non-standard generated headers From: Iain Nicol To: bug-automake@gnu.org Content-Type: text/plain; charset=ISO-8859-1 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -5.1 (-----) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Tue, 09 Aug 2011 11:41:25 -0400 Cc: 7648@debbugs.gnu.org, Stefano Lattarini X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.6 (-----) 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: 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 14 05:40:27 2012 Received: (at 7648) by debbugs.gnu.org; 14 Jul 2012 09:40:27 +0000 Received: from localhost ([127.0.0.1]:40274 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Spypv-0007cI-33 for submit@debbugs.gnu.org; Sat, 14 Jul 2012 05:40:27 -0400 Received: from mail-bk0-f44.google.com ([209.85.214.44]:60943) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Spypt-0007cB-D3 for 7648@debbugs.gnu.org; Sat, 14 Jul 2012 05:40:25 -0400 Received: by bkty7 with SMTP id y7so3109859bkt.3 for <7648@debbugs.gnu.org>; Sat, 14 Jul 2012 02:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:mime-version:to:cc:subject:content-type :content-transfer-encoding; bh=GqTCgSyKVyqpuiAHoqpEft+6rbltODksECjmPP+7D7s=; b=ZfkextQhryZikb+Xmhc1SUwb450MC/i3tO80ba0NUodv4BfNSkx47S9YRk+zOHj4ud v7U1UI3cE4FhD5evBippl8LMzZxoQG+xJcz3DuWR0MuX3nk7RJfHjEwkYttdpkPwu7bJ aMt+AYX0P0uJI72trih7scN6b5lxpv5iZNOpk4/tQFJd4gk7oHiJCBOD3Il1+S7O2n9y Sj25or43+Fk6Q9KSSNf5YR4XfffYqqBoox7WrTqv+Rhb+TqCr66PLn/2i7mUUn9Gah6V DF9Zxq7ywUw1AtIvXqFtf74SfE5SfQe1y/+thfb9qCeuZIvPtfk7E7lfOYKLAAnxHRVZ GauA== Received: by 10.205.123.134 with SMTP id gk6mr2433085bkc.3.1342258482061; Sat, 14 Jul 2012 02:34:42 -0700 (PDT) Received: from [79.10.95.133] (host133-95-dynamic.10-79-r.retail.telecomitalia.it. [79.10.95.133]) by mx.google.com with ESMTPS id gq2sm5627425bkc.13.2012.07.14.02.34.39 (version=SSLv3 cipher=OTHER); Sat, 14 Jul 2012 02:34:41 -0700 (PDT) Message-ID: <50013D2D.8010608@gmail.com> Date: Sat, 14 Jul 2012 11:34:37 +0200 From: Stefano Lattarini MIME-Version: 1.0 To: bug-automake@gnu.org Subject: Re: ylwrap appears not to support bison's lalr1.cc skeleton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 7648 Cc: 7648@debbugs.gnu.org, James Bostock , Iain Nicol X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Reference: 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: and in particular the messages: I will proceed to close this bug report once those patches are actually merged into maint. Regards, Stefano From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 16 05:23:51 2012 Received: (at 7648-done) by debbugs.gnu.org; 16 Jul 2012 09:23:51 +0000 Received: from localhost ([127.0.0.1]:43711 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SqhWw-0005m1-7t for submit@debbugs.gnu.org; Mon, 16 Jul 2012 05:23:50 -0400 Received: from mail-bk0-f44.google.com ([209.85.214.44]:56115) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SqhWt-0005ls-Pw for 7648-done@debbugs.gnu.org; Mon, 16 Jul 2012 05:23:48 -0400 Received: by bkty7 with SMTP id y7so3709411bkt.3 for <7648-done@debbugs.gnu.org>; Mon, 16 Jul 2012 02:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=asTBt4YWKlO7vMNBNzX95oCpDejvvVy5DTU7IvTskFA=; b=VcruvOIHxetuLXC6Kd3U1/zr3NSa2OXiwvVIWcOMxh2PdAM1d/vX8fNiFQF97wJjmz CX9BTXvCwlXuhP945x4okybeG8WJY/1P3DO7lW20SMyphT44pYC1G6si+3XvIlCy93/a 56HXTyVVDrBKmk1X2qWbK0giCjfz+mF13PSaBU6meOIapdggK5DiuyzxEc4FBa2cMQYl rRatthPrNto8qMwXUpdCXLuHkkx3WWLmm/dJc+cPgXKtoZ4jseRnmFbs/r0pXX4pGn+x mHWOZW7ET9M+P07Nl8g3I8VlGRIvHCoTmOA3pPlPe9fG6xoX6kFwUqE8XF0j/e+F6KJ5 5/6Q== Received: by 10.204.128.202 with SMTP id l10mr4332312bks.127.1342430273339; Mon, 16 Jul 2012 02:17:53 -0700 (PDT) Received: from [82.54.101.70] (host70-101-dynamic.54-82-r.retail.telecomitalia.it. [82.54.101.70]) by mx.google.com with ESMTPS id n5sm2903843bkv.14.2012.07.16.02.17.50 (version=SSLv3 cipher=OTHER); Mon, 16 Jul 2012 02:17:51 -0700 (PDT) Message-ID: <5003DC3D.1090001@gmail.com> Date: Mon, 16 Jul 2012 11:17:49 +0200 From: Stefano Lattarini MIME-Version: 1.0 To: 7648-done@debbugs.gnu.org Subject: Re: bug#7648: ylwrap appears not to support bison's lalr1.cc skeleton References: <50013D2D.8010608@gmail.com> In-Reply-To: <50013D2D.8010608@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 7648-done Cc: james.bostock@gmail.com, iain@thenicols.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 07/14/2012 11:34 AM, Stefano Lattarini wrote: > Reference: > > 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: > > and in particular the messages: > > > > 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 From unknown Sun Jun 22 17:15:43 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 13 Aug 2012 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator