Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Stan Shebs <stan@codesourcery.com>
To: "Joseph S. Myers" <joseph@codesourcery.com>
Cc: Stan Shebs <stan@codesourcery.com>, gdb@sourceware.org
Subject: Re: Autogenerate gdbarch doc for internals manual
Date: Fri, 01 Aug 2008 17:39:00 -0000	[thread overview]
Message-ID: <48934A42.7060307@codesourcery.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0808011719410.3945@digraph.polyomino.org.uk>

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


  reply	other threads:[~2008-08-01 17:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-01 17:06 Stan Shebs
2008-08-01 17:22 ` Joseph S. Myers
2008-08-01 17:39   ` Stan Shebs [this message]
2008-08-01 17:51     ` Mark Kettenis
2008-08-01 18:38     ` Eli Zaretskii
2008-08-01 18:50       ` Daniel Jacobowitz
2008-08-01 18:35   ` Eli Zaretskii
2008-08-01 18:55     ` Stan Shebs
2008-08-01 18:32 ` Eli Zaretskii
2008-08-01 18:34 ` Jeremy Bennett

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=48934A42.7060307@codesourcery.com \
    --to=stan@codesourcery.com \
    --cc=gdb@sourceware.org \
    --cc=joseph@codesourcery.com \
    /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