This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch][gdb,etc] Add configure option to disable building internal documentation.
> Date: Wed, 07 Nov 2007 11:22:12 -0800
> From: Brooks Moses <brooks@codesourcery.com>
> CC: gdb-patches@sourceware.org
>
> If that was set up with "make install-pdf", there will be
> four or five manuals in there -- three of which are irrelevant to their
> needs, and which they don't want. And it's not entirely obvious which
> one the user wants to look at first, if they are unfamiliar with GDB and
> have a question they want to find an answer to. That seems confusing to
> me, and is clutter in the sense that that's a considerable quantity of
> bloat in the package size and its disk-space requirements that is
> essentially pointless.
I really don't feel we are entitled to second-guess the user's needs.
The manuals that come with GDB are all useful one way or the other;
it's up to the user to remove those she knows she will never need.
> Add up the sizes of the pdf, info, and html files, and the space
> usage is considerable.
Actually, I doubt it's considerable by modern standards, but even if
it is, why would someone want to install all 3 formats by default?
You only need one (any one).
> Meanwhile, if things _are_ installed into /usr/local/info, consider the
> filenames involved. "Annotate" and "stabs" are not names that have any
> obvious relation to GDB; it seems unlikely that an end-user will have
> any idea what they are if they do come across them.
You are reading too much into the names. You assume that the user
looks at the file names and somehow decides what she needs to read or
search judging by the names. But at least with Info manuals, that's
not the case: the user looks at the short descriptions in the DIR's
master menu, or invokes some global search command, like info-apropos.
So I really don't think the file names are too important. Moreover,
if we look at other packages, we will see even more cryptic file
names: for example, what is `eintr' in Emacs? would you know that it's
the Introduction to Emacs Lisp? does this mean this manual is
``clutter''?
> However, at the level of someone who is making a package of the software
> to distribute, these are definitely clutter, and I expect that many
> people who produce packages of the GNU toolchain already have some
> (fragile, manual) process for taking out the extraneous manuals before
> packaging it. Automating and standardizing that -- and providing a
> means by which the developers can easily identify new manuals as useful
> for end-users or not -- seems a distinct benefit to the community.
People who produce packages are experienced users; they know what they
do. I'm not sure we should propagate their system- and
package-system-specific choices upstream.
In sum, I cannot say I like this feature; it almost sounds to me like
something we should at least ask RMS about, as it goes against
long-standing policy of the GNU project.
Anyway, if we are going to have such a feature, I'd prefer a special
Makefile target for this, not a configure option. This way, one can
install either the whole set of manuals or its subset, without the
need to reconfigure.
And the default ("make info" and "make install-info") must stay to
install everything, of course.