From: "Dave Korn" <dave.korn@artimi.com>
To: "'Konstantin Karganov'" <kostik@ispras.ru>,
"'Eli Zaretskii'" <eliz@gnu.org>
Cc: <gdb@sources.redhat.com>
Subject: RE: Re[2]: complete GDB MI specification
Date: Wed, 08 Dec 2004 17:01:00 -0000 [thread overview]
Message-ID: <NUTMEGmjpD3zCParqjP000004d3@NUTMEG.CAM.ARTIMI.COM> (raw)
In-Reply-To: <9825395456.20041208194459@ispras.ru>
> -----Original Message-----
> From: gdb-owner On Behalf Of Konstantin Karganov
> Sent: 08 December 2004 16:45
> > But basically, I think that once the Yacc parser is written and
> > becomes part of GDB, we should maintain the parser instead of
> > documenting the grammar.
> Yes, I've also got this idea - it's better not to develop parsers
> every time from the scratch, but to have a "standard" parser since it
> fits the main goal of the MI interface project. In this case it can be
> easily made consistent with current MI version (as supported by the
> same team). Anyhow, the detailed semantics description of the parser
> output should be available, here I completely disagree with the
> position "maintain instead of documenting" (literally, as it was
> mentioned).
Maybe the best solution would be to use one of those auto-documentation format
where comments in the source code for the parser are extracted and used to
generate the docs? I quite like doxygen, but it's probably not the right tool
for this job: a) it would be yet another tool that developers would have to
install in addition to all the auto* tools etc., b) it's a rather overengineered
and heavyweight solution to the problem and c) it doesn't generate .texi output
(AFAIR, but don't quote me on that).
Actually, maybe the simplest solution would be to provide a second yacc
parser, to parse the comments out of the first parser and output them in .texi
format so they can be included in the documentation build automatically....
cheers,
DaveK
--
Can't think of a witty .sigline today....
prev parent reply other threads:[~2004-12-08 17:01 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-29 14:06 (a?)synchronous stepping commands in gdb MI, a week later Konstantin Karganov
2004-11-29 16:08 ` Andrew Cagney
2004-11-29 19:59 ` Re[2]: " Konstantin Karganov
2004-12-06 16:19 ` complete GDB MI specification Konstantin Karganov
2004-12-06 20:55 ` Eli Zaretskii
2004-12-07 18:42 ` Re[2]: " Konstantin Karganov
2004-12-07 18:58 ` Bob Rossi
2004-12-07 19:45 ` Eli Zaretskii
2004-12-07 19:50 ` Bob Rossi
2004-12-07 21:47 ` Eli Zaretskii
2004-12-07 19:42 ` Eli Zaretskii
2004-12-08 16:42 ` Re[2]: " Konstantin Karganov
2004-12-08 16:53 ` Bob Rossi
2004-12-08 17:45 ` Re[2]: " Konstantin Karganov
2004-12-08 18:30 ` Bob Rossi
2004-12-08 18:34 ` Bob Rossi
2004-12-08 18:39 ` Re[2]: " Konstantin Karganov
2004-12-08 17:01 ` Dave Korn [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=NUTMEGmjpD3zCParqjP000004d3@NUTMEG.CAM.ARTIMI.COM \
--to=dave.korn@artimi.com \
--cc=eliz@gnu.org \
--cc=gdb@sources.redhat.com \
--cc=kostik@ispras.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox