Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Brooks Moses <brooks@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [patch][gdb,etc] Add configure option to disable building internal   documentation.
Date: Wed, 07 Nov 2007 22:22:00 -0000	[thread overview]
Message-ID: <uabppr900.fsf@gnu.org> (raw)
In-Reply-To: <47321064.5040306@codesourcery.com> (message from Brooks Moses on 	Wed, 07 Nov 2007 11:22:12 -0800)

> 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.


  parent reply	other threads:[~2007-11-07 22:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-06 23:18 Brooks Moses
2007-11-07  2:54 ` Daniel Jacobowitz
2007-11-07  4:10 ` Eli Zaretskii
2007-11-07 19:22   ` Brooks Moses
2007-11-07 20:52     ` Joel Brobecker
2007-11-07 22:22     ` Eli Zaretskii [this message]
2007-11-07 23:50       ` Mark Kettenis

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=uabppr900.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=brooks@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    /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