From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30742 invoked by alias); 28 Jan 2003 07:30:50 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 30735 invoked from network); 28 Jan 2003 07:30:50 -0000 Received: from unknown (HELO gold.csi.cam.ac.uk) (131.111.8.12) by 172.16.49.205 with SMTP; 28 Jan 2003 07:30:50 -0000 Received: from student.cusu.cam.ac.uk ([131.111.179.82] helo=kern.srcf.societies.cam.ac.uk ident=mail) by gold.csi.cam.ac.uk with esmtp (Exim 4.10) id 18dQCn-0007DG-00; Tue, 28 Jan 2003 07:30:49 +0000 Received: from jsm28 (helo=localhost) by kern.srcf.societies.cam.ac.uk with local-esmtp (Exim 3.35 #1 (Debian)) id 18dQCn-0004zL-00; Tue, 28 Jan 2003 07:30:49 +0000 Date: Tue, 28 Jan 2003 12:30:00 -0000 From: "Joseph S. Myers" X-X-Sender: To: Bruce Korb cc: gcc , Subject: Re: Slightly more extended example for named diagnostics In-Reply-To: <3E35EDC4.3AE07104@veritas.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2003-01/txt/msg01443.txt.bz2 On Mon, 27 Jan 2003, Bruce Korb wrote: > All done. :-) Over-simplified, you haven't handled all the messages that aren't covered by the diagnostic machinery (from miscellaneous programs outside cc1 etc.), or the various message fragments marked with N_ and _ for gettext to extract them (which may in future need to be duplicated, preceded by various codes, in order to handle the various ways in which they are declined in sentences in various languages). I don't recommend generating a .pot file directly rather than using gettext - better to run gettext on the generated source file and work out how to get original source locations into the .pot file rather than references to the generated file. > How would you like it structured? How about putting all the > details in a numericly ordered section and indexed by name > and sections for each named group that also have indexes > into it for each member of each group? The groupings ought to go > into the full index, but I think I would omit individual > warnings. Anything else? It will be very easy, regardless of > how you want it formatted. Ordered in some vaguely logical conceptual way. The arrangement of sections in the standard isn't bad, but complicated by messages shared by C and C++. Where front ends have their own manuals, messages get documented in those manuals. And a properly aesthetic printed manual requires that the documentation is in Texinfo format. You avoid needing to duplicate makeinfo within gcc if you just say "see info gcc whatever for details" and put the documentation in the manual rather than the source, then the source just needs to reference the manual and you can arrange for the node (or the anchor within the node) to be named after the message identifier. -- Joseph S. Myers jsm28@cam.ac.uk