This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: [PATCH] GDB command-line switches and annotations docs
Eli Zaretskii writes:
>
> Elena Zannoni writes:
>
> > > (Are there plans to make gdbmi.texi be part of the manual as well?)
> > >
> >
> > Eventually yes (Andrew?), right now it is not in prime time form yet. It is
> > still very rough work in progress.
>
> IMHO, it is much better to link between the two right now, and make
> any necessary corrections later. As far as I could see, gdbmi.texi is
> in quite a good shape, it just lacks a few menus and @node lines to
> make it a valid Texinfo file. Most of the work can be done in Emacs
> automatically.
>
> The current situation, where a large part opf the package is not
> documented at all, is IMHO much worse.
>
> I can throw together a few patches as outlined above, if that would
> help.
>
I agree with you, but at present the contests of gdbmi.texi are out of
date in a few places. Andrew or I should go through it and make it
better match with the actual MI functions. It shouldn't take long, but
I don't have much time at this moment.
> > I was planning on removing the -async option, it is now redundant.
>
> It's much easier to remove part of the docs than to write it ;-)
> Anyway, if -noasync stays, you will need some of what I wrote under
> its description.
>
Yes, definitely.
> > The behavior you describe is the ultimate goal, we are only
> > about 50% there.
>
> The truth is, I still don't know enough about the event loop's
> interaction with the target side to write the docs about it. But I
> thought there was no better way to get attention to its being
> undocumented than to throw some patches on you-all ;-). I do think
> that refining the description should be the job of someone who knows
> the fine details.
>
I admit I haven't documented the event loop machinery at all (that
should actually go in the internal manual). I thoroughly commented the
code though, if that's any excuse :-).
I wasn't going to document the existance of target 'async' either,
because that's also supposed to go away, and be absorbed into a new
and improved target 'remote'. There are still a bunch of loose ends to
finish before that's going to happen. So I am not sure what the best
course of action is.
Elena