From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25632 invoked by alias); 1 Aug 2008 17:22:44 -0000 Received: (qmail 25621 invoked by uid 22791); 1 Aug 2008 17:22:43 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 01 Aug 2008 17:22:15 +0000 Received: (qmail 11700 invoked from network); 1 Aug 2008 17:22:13 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 1 Aug 2008 17:22:13 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.68) (envelope-from ) id 1KOyKS-0007Zq-FU; Fri, 01 Aug 2008 17:22:12 +0000 Date: Fri, 01 Aug 2008 17:22:00 -0000 From: "Joseph S. Myers" To: Stan Shebs cc: gdb@sourceware.org Subject: Re: Autogenerate gdbarch doc for internals manual In-Reply-To: <4893427D.1000909@codesourcery.com> Message-ID: References: <4893427D.1000909@codesourcery.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-08/txt/msg00024.txt.bz2 On Fri, 1 Aug 2008, Stan Shebs wrote: > Undeterred by the stunning lack of response to my last internals manuals query > (http://sourceware.org/ml/gdb/2008-07/msg00309.html, not too late to speak up > :-) ), I bring up an idea suggested on irc, which is to generate the internals > manual's detailed description of gdbarch methods from gdbarch.sh . Although > I'm not generally a fan of autogenerated docs - I find they tend to be heavy > on syntax, and light on semantics - the internals manual has fallen way behind > what is actually in gdbarch, and there are other manual sections that can talk > more about how all the different methods work together. > > Mechanically, the way I see it working is that running gdbarch.sh produces a > third file, doc/gdbarch.texi, which is then included in doc/gdbint.texinfo. > Some gdbint.texinfo bits will migrate into gdbarch.sh; I don't think there > will be a problem including texinfo markup in gdbarch.sh, just need basic > @foo{} constructs to get passed through. This is going to be more of a > background task for me, but I wanted to get some agreement on the direction > before starting to tinker. You have the issue that's been discussed before in the GCC context: the need for an appropriate license text on gdbarch.sh to allow parts of it to be used in the manual that's under a different license from the code. Good luck getting the FSF to produce a GPLv3 exception text for this in reasonable time given how long all the other exceptions have taken so far (getting the manual GPLed seems even less likely). -- Joseph S. Myers joseph@codesourcery.com