This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA][patch 1/9] Yet another respin of the patch with initial Python support


> Cc: bauerman@br.ibm.com, gdb-patches@sourceware.org
> From: Tom Tromey <tromey@redhat.com>
> Date: Sat, 26 Jul 2008 11:09:59 -0600
> 
> Daniel> Ok, in that case I have an alternative suggestion: how about renaming
> Daniel> the combined scripting chapter, and putting both Python scripting and
> Daniel> the existing information in the new chapter?
> 
> I don't really want to merge them.  I don't think it provides much
> benefit to the reader of the manual.

The benefit is more structure.  Both Python support and the old way of
defining user-defined commands is about the same thing: extending GDB.

> It might make sense to document the "python" command alongside
> "define" or what have you -- but I think only barely, since the
> "python" command is kinda pointless without the rest of the API.

I don't see why this invalidates the merge.  Please explain.

> In the long run the Python chapter is going to be 99% documentation of
> the Python API, something that will hold little interest to the casual
> gdb user.

That's why it will be in a different section.

> I guess we could even go so far as to make a separate python API
> manual.  That seemed like more of a pain though; I wasn't sure what
> the benefit of that would be either.

I agree: there's no sense of having such a separate manual.
Determining where we stop describing Python in the GDB manual will be
a challenge, but it shouldn't IMO prevent us from trying to have some
reasonable structure on the top level.  Having too many chapters is
not a good sign.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]