This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: gdb.texinfo is getting too big
- From: Pedro Alves <palves at redhat dot com>
- To: Paul_Koning at Dell dot com
- Cc: eliz at gnu dot org, dje at google dot com, gdb-patches at sourceware dot org, stan at codesourcery dot com
- Date: Wed, 16 Oct 2013 22:39:15 +0100
- Subject: Re: gdb.texinfo is getting too big
- Authentication-results: sourceware.org; auth=none
- References: <CADPb22S7Yjz=um_7P_9M_yS-ko7+jNQXzf8HqtWn3QdWqoD2DA at mail dot gmail dot com> <83ob6rpqa5 dot fsf at gnu dot org> <CADPb22SdNrdrhsQJuQYAzQTEQtj7j+Pwf5VQo05qUETLJ5Zbuw at mail dot gmail dot com> <83mwmbp80v dot fsf at gnu dot org> <CADPb22QOG=kH_HPr59rEZEQPhQh0QS_JYi82W-McmfLf+fifCA at mail dot gmail dot com> <83zjq9nipu dot fsf at gnu dot org> <525EEE89 dot 9060907 at redhat dot com> <83txghnfpe dot fsf at gnu dot org> <C75A84166056C94F84D238A44AF9F6AD0372DC69 at AUSX10MPC103 dot AMER dot DELL dot COM>
On 10/16/2013 09:10 PM, Paul_Koning@Dell.com wrote:
>
> On Oct 16, 2013, at 4:06 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>>> Date: Wed, 16 Oct 2013 20:52:41 +0100
>>> From: Pedro Alves <palves@redhat.com>
>>> CC: Doug Evans <dje@google.com>, gdb-patches@sourceware.org,
>>> stan@codesourcery.com
>>>
>>> Maybe it'd be easier to think in terms of things that would make
>>> sense to split out of the main file. E.g., the RSP chapter is useful
>>> for GDB and stub developers, but not for regular users -- split that
>>> one out. Python scripting API stuff is useful for advanced users
>>> that want to extend GDB, but it's not really the same class of manual
>>> as the other chapters, so split that one out as another file too.
>>> MI is useful for frontend writers, not for regular users, so out it
>>> goes too. Whatever other identifiable logic units we find, split
>>> them out. Then I suspect we'll end up with the core manual for
>>> regular users that describes GDB's main features/CLI/commands,
>>> and it'll be lean enough to be manageable.
>>
>> You are talking about splitting the manual, whereas Doug was talking
>> about splitting the sources while keeping a single manual as output.
>>
>> I'm not sure I see a good reason to split the manual. For starters,
>> the size of that doesn't hurt as much as the size of the source file
>> when you need to edit it.
>
> Agreed. There are plenty of examples of large manuals (GCC, GCCint, Emacs). Divide them into as many source files as is convenient, that doesn't bother any user. But having the manual (what users read) split into multiple parts is not a good change.
>
> If we ever hit 5000 pages I might change my tune, but no GDB documentation is even close to that big.
I was not suggesting to split the resulting produced manual.
Sorry if I wasn't clear. I guess I should have said "core file"
where it reads "core manual". I don't see a need to for
a user visible split either. My response was in response to
"The worry I have with any kind of grouping not based on the doc itself
is that it introduces a potentially non-intuitive layer that someone
has to learn in order to know which file contains the text one wants
to edit."
and I was presenting a rationale for splitting around logical
grouping units.
--
Pedro Alves