From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9499 invoked by alias); 7 Nov 2007 22:22:52 -0000 Received: (qmail 9488 invoked by uid 22791); 7 Nov 2007 22:22:51 -0000 X-Spam-Check-By: sourceware.org Received: from nitzan.inter.net.il (HELO nitzan.inter.net.il) (213.8.233.22) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 07 Nov 2007 22:22:44 +0000 Received: from HOME-C4E4A596F7 (IGLD-83-130-247-76.inter.net.il [83.130.247.76]) by nitzan.inter.net.il (MOS 3.7.3a-GA) with ESMTP id IGK41115 (AUTH halo1); Thu, 8 Nov 2007 00:20:04 +0200 (IST) Date: Wed, 07 Nov 2007 22:22:00 -0000 Message-Id: From: Eli Zaretskii To: Brooks Moses CC: gdb-patches@sourceware.org In-reply-to: <47321064.5040306@codesourcery.com> (message from Brooks Moses on Wed, 07 Nov 2007 11:22:12 -0800) Subject: Re: [patch][gdb,etc] Add configure option to disable building internal documentation. Reply-to: Eli Zaretskii References: <4730F626.806@codesourcery.com> <47321064.5040306@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-11/txt/msg00145.txt.bz2 > Date: Wed, 07 Nov 2007 11:22:12 -0800 > From: Brooks Moses > 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.