From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8369 invoked by alias); 1 Aug 2008 17:39:50 -0000 Received: (qmail 8318 invoked by uid 22791); 1 Aug 2008 17:39:47 -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:39:21 +0000 Received: (qmail 13163 invoked from network); 1 Aug 2008 17:39:19 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 1 Aug 2008 17:39:19 -0000 Message-ID: <48934A42.7060307@codesourcery.com> Date: Fri, 01 Aug 2008 17:39:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: "Joseph S. Myers" CC: Stan Shebs , gdb@sourceware.org Subject: Re: Autogenerate gdbarch doc for internals manual References: <4893427D.1000909@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00025.txt.bz2 Joseph S. Myers wrote: > 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). > Ouch, I hadn't even thought of that! But then how does that work for libiberty, which collects snippets from LGPL files and pastes them into functions.texi, which is included in the GFDLed manual? Stan