From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19343 invoked by alias); 1 Nov 2013 19:37:57 -0000 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 Received: (qmail 19332 invoked by uid 89); 1 Nov 2013 19:37:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-vb0-f48.google.com Received: from mail-vb0-f48.google.com (HELO mail-vb0-f48.google.com) (209.85.212.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 01 Nov 2013 19:37:56 +0000 Received: by mail-vb0-f48.google.com with SMTP id o19so3062070vbm.7 for ; Fri, 01 Nov 2013 12:37:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PZ/jFYCjuLOTKkFG6kyQ2NijU0f06MbqKLSj3Gee/VU=; b=W/Qqm1r6XutABgO8AQTA5AKmqAdGcTgWZMqyHXDJ1Vp7lMX2aOUkcV994H8ngrHlzi L9PLBswH66h9HI0ygDN4vmO5ejLIvvp2JnifHyqGkg1brJHw9d9c/exOJBpB17Ge/bbk EeBkzTKQvS6bvTUbx4xJVrM2tj7ZENJucZSth4n2IyMJUgwc/41bt9ZBBRv9h0UIQEbA sx2DNhmQswCdKQbnlFcEXzKubZ4mlFmN0xiUqYbIo/HXcZP44pBHWET6BSzN6whIVi8H PGs7bMjE2avcbouPctGkG/AvBQka/RW1LISpFYBIqS8POrb+Q4DPz3aWr8rq6ZXiFf9K wejQ== X-Gm-Message-State: ALoCoQmxo3IeJ1Kcq4nYeO9ovwqoNzdrgYbGRPjpsRxXqsZHD9ldrNTSkqa8Gf1esUMWqNLyzErcPP4cq6+S/ip1yIQzD6U07ErIUgVryGpQPUb4LGQ0Tdkx4WO2orFfak+D8ok4/BF49Z8EpaYDT/bYOo3IF1ea4J7iIGaowMmhmOZetc69ZQE+EM03MJp7goev2bEMQgAy7Nlydc1uXPsZNpVLTqdUxw== MIME-Version: 1.0 X-Received: by 10.52.164.16 with SMTP id ym16mr360113vdb.39.1383334673931; Fri, 01 Nov 2013 12:37:53 -0700 (PDT) Received: by 10.52.237.232 with HTTP; Fri, 1 Nov 2013 12:37:53 -0700 (PDT) In-Reply-To: <525F0783.5000907@redhat.com> References: <83ob6rpqa5.fsf@gnu.org> <83mwmbp80v.fsf@gnu.org> <83zjq9nipu.fsf@gnu.org> <525EEE89.9060907@redhat.com> <83txghnfpe.fsf@gnu.org> <525F0783.5000907@redhat.com> Date: Fri, 01 Nov 2013 19:37:00 -0000 Message-ID: Subject: Re: gdb.texinfo is getting too big From: Doug Evans To: Pedro Alves Cc: Paul Koning , Eli Zaretskii , gdb-patches , Stan Shebs Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg00017.txt.bz2 On Wed, Oct 16, 2013 at 2:39 PM, Pedro Alves wrote: > On 10/16/2013 09:10 PM, Paul_Koning@Dell.com wrote: >> >> On Oct 16, 2013, at 4:06 PM, Eli Zaretskii wrote: >> >>>> Date: Wed, 16 Oct 2013 20:52:41 +0100 >>>> From: Pedro Alves >>>> CC: Doug Evans , 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. If people are ok with logical grouping units it's fine with me. One fear I have is a protracted discussion on the groupings. I do like the idea of splitting out pieces that are easy to split out. E.g., RSP, Python, maybe a few others. How about starting with that?