GNU bug report logs - #10825
Better bison support in Automake (was: Re: FYI: master: calc++: rely on Automake)

Previous Next

Package: automake;

Reported by: Stefano Lattarini <stefano.lattarini <at> gmail.com>

Date: Thu, 16 Feb 2012 10:25:01 UTC

Severity: normal

Tags: confirmed, help

To reply to this bug, email your comments to 10825 AT debbugs.gnu.org.

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

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


Report forwarded to bug-automake <at> gnu.org:
bug#10825; Package automake. (Thu, 16 Feb 2012 10:25:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stefano Lattarini <stefano.lattarini <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-automake <at> gnu.org. (Thu, 16 Feb 2012 10:25:01 GMT) Full text and rfc822 format available.

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Akim Demaille <akim <at> lrde.epita.fr>
Cc: bug-automake <at> gnu.org, Bison Patches <bison-patches <at> gnu.org>,
	automake-patches <at> gnu.org
Subject: Better bison support in Automake (was: Re: FYI: master: calc++: rely
	on Automake)
Date: Thu, 16 Feb 2012 11:21:31 +0100
[Message part 1 (text/plain, inline)]
[CC:ing bug-automake, so that we won't forget about the issues raised here]

Hi Akim.

On 02/15/2012 01:31 PM, Akim Demaille wrote:
> 
> Le 15 févr. 2012 à 13:18, Stefano Lattarini a écrit :
> 
>> On 02/15/2012 11:36 AM, Akim Demaille wrote:
>>> Rely on $(YACC) being the bison being built, and let Automake do the
>>> rest.  It turned out to be much more difficult than anticipated, for
>>> various reasons, including some bad behavior from Automake 1.11.2
>>> which (i) generates calc++-parser.h instead of calc++-parser.hh,
>>>
>> FYI: this will be fixed in automake 1.12 -- the patch fixing it being
>> already merged into master.
> 
> Thanks Stefano!
> 
> I can't clone automake right now (Savannah seems to be overloaded),
> so I can't check the following typo in the current documentation.
> It should take you only a couple of seconds to check.
> 
>>    ---------- Footnotes ----------
>>
>>    (1) Please note that `automake' recognizes `-d' in `AM_YFLAGS' only
>> if it is not clustered with other options; for example, it won't be
>> recognized if `AM_YFLAGS' is `-dt', but it will be if `AM_YFLAGS' is
>> `-d -t' or `-d -t'
> 
> I guess the latter is `-t -d', and the period is missing.
>
Thanks, fixed (see attached patch).

> But maybe automake no longer needs this?
>
It still need it; without that, no header file will be generated from
the '.y' files (this is a feature, not a bug).

> If it does, it would be good to recognize also --defines.
> 
Maybe; but then, it should be done right, i.e., automake should also
understand hand handle the '--defines=my-hdr.h' usage.  But I guess
this would conflict with ylwrap in some way, sigh :-(

Maybe it's truly time to introduce a new AM_PROG_BISON macro that
will cause automake to drop all the cruft related to POSIX yacc
compatibility ...  As usual, patches welcome ;-)

Regards,
  Stefano
[0001-docs-fix-typo-in-description-of-AM_YFLAGS.patch (text/x-diff, attachment)]

Information forwarded to bug-automake <at> gnu.org:
bug#10825; Package automake. (Thu, 16 Feb 2012 17:10:02 GMT) Full text and rfc822 format available.

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

From: Akim Demaille <akim <at> lrde.epita.fr>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: bug-automake <at> gnu.org, Bison Patches <bison-patches <at> gnu.org>,
	automake-patches <at> gnu.org
Subject: Re: Better bison support in Automake (was: Re: FYI: master: calc++:
	rely on Automake)
Date: Thu, 16 Feb 2012 12:25:40 +0100
[Message part 1 (text/plain, inline)]
Le 16 févr. 2012 à 11:21, Stefano Lattarini a écrit :

> Hi Akim.

Hi!

> Thanks, fixed (see attached patch).
> 
>> But maybe automake no longer needs this?
>> 
> It still need it; without that, no header file will be generated from
> the '.y' files (this is a feature, not a bug).
> 
>> If it does, it would be good to recognize also --defines.
>> 
> Maybe; but then, it should be done right, i.e., automake should also
> understand hand handle the '--defines=my-hdr.h' usage.  But I guess
> this would conflict with ylwrap in some way, sigh :-(
> 
> Maybe it's truly time to introduce a new AM_PROG_BISON macro that
> will cause automake to drop all the cruft related to POSIX yacc
> compatibility ...  As usual, patches welcome ;-)

One of the problems that you would face is that it's hard
to know what files will be created by Bison.  Actually,
bison and only bison can know.  For instance currently
for C++ it generates stack.hh and other files that users
find painful to deal with, so I plan to have them go
into the generated *.cc file, upon user request.  This is
not something automake should know.

What would be your preferred option?  Would you like some sort
of --dry-run option that would in addition send the list of created
files on stdout?  Or an option to generate an additional file
with the list of the generated files during the normal run?
Or a Makefile snippet a la -M.

FWIW, I also use a wrapper around Bison, for several reasons:
I like to see the diffs, I want to run xsltproc to get the HTML
report, I want to keep old timestamps when possible, I'd like
to "optimize" some part of the output, etc.

Someone might find them useful, so here they are.

[bison++.in (application/octet-stream, attachment)]
[fuse-switch (application/octet-stream, attachment)]

Added tag(s) help. Request was from Karl Berry <karl <at> freefriends.org> to control <at> debbugs.gnu.org. (Fri, 20 Nov 2020 02:06:02 GMT) Full text and rfc822 format available.

Added tag(s) confirmed. Request was from Karl Berry <karl <at> freefriends.org> to control <at> debbugs.gnu.org. (Fri, 20 Nov 2020 02:06:02 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 170 days ago.

Previous Next


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