From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30343 invoked by alias); 8 Dec 2004 17:01:18 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 30302 invoked from network); 8 Dec 2004 17:01:12 -0000 Received: from unknown (HELO NUTMEG.CAM.ARTIMI.COM) (217.40.111.177) by sourceware.org with SMTP; 8 Dec 2004 17:01:12 -0000 Received: from mace ([192.168.1.25]) by NUTMEG.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Dec 2004 16:59:36 +0000 From: "Dave Korn" To: "'Konstantin Karganov'" , "'Eli Zaretskii'" Cc: Subject: RE: Re[2]: complete GDB MI specification Date: Wed, 08 Dec 2004 17:01:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In-Reply-To: <9825395456.20041208194459@ispras.ru> Message-ID: X-OriginalArrivalTime: 08 Dec 2004 16:59:36.0156 (UTC) FILETIME=[4C0D19C0:01C4DD47] X-SW-Source: 2004-12/txt/msg00056.txt.bz2 > -----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....