From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11301 invoked by alias); 8 Aug 2014 06:05:00 -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 11287 invoked by uid 89); 8 Aug 2014 06:05:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout23.012.net.il Received: from mtaout23.012.net.il (HELO mtaout23.012.net.il) (80.179.55.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 08 Aug 2014 06:04:57 +0000 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0N9Z00K004HIF700@a-mtaout23.012.net.il> for gdb-patches@sourceware.org; Fri, 08 Aug 2014 09:04:54 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N9Z00KU14W5FC00@a-mtaout23.012.net.il>; Fri, 08 Aug 2014 09:04:54 +0300 (IDT) Date: Fri, 08 Aug 2014 06:05:00 -0000 From: Eli Zaretskii Subject: Re: [doc] Avoid conflicts between gdb and cross-gdb. In-reply-to: <6996949.EeennEHWE2@vapier> To: Mike Frysinger Cc: brobecker@adacore.com, gdb-patches@sourceware.org, monaka@monami-software.com Reply-to: Eli Zaretskii Message-id: <83lhqzms89.fsf@gnu.org> References: <5772813.BLhj1dYueK@vapier> <8338d8nvsc.fsf@gnu.org> <6996949.EeennEHWE2@vapier> X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00161.txt.bz2 > From: Mike Frysinger > Cc: brobecker@adacore.com, gdb-patches@sourceware.org, monaka@monami-software.com > Date: Thu, 07 Aug 2014 22:52:57 -0400 > > so the first question is, is this scenario important to us ? or do we > consider people dealing with cross-gdb's to be on their own and to figure out > documentation skew problems themselves ? I see no documentation skews here. The GDB manual documents (barring errors that should be reported and fixed) describes all of its versions, including cross-gdb. The names of the Info files that constitute the manual are not important. If we want to do anything that really matters, we should add rules to insert menu items into the DIR menu that name the cross-gdb that is being installed, and point to the same GDB manual whose file name is always gdb.info. And even this is a minor issue, as a person who builds and uses cross-gdb surely knows that she builds and uses GDB. > lumping it into the category of "if you're > cross-compiling/debugging, you know what you're doing" doesn't fly > as there a _lot_ of people who do cross work and know very little > here -- someone else is responsible for building/packaging the > toolchain and they were just given it and told "use xxx-gcc and > xxx-gdb". I don't see how people who know very little could ever be able to work with GDB, or even with a cross-compiler, for that matter. But I guess we will have to agree to disagree here. > i think it's useful to have the full manual with the right version available > on a per-target basis, but maybe others here don't think it's useful enough to > justify the work to make the info pages work. i.e. more of the ongoing > maintenance cost rather than just the initial up-front cost. maybe we can get > assistance from the texinfo project to make this scenario easier so we don't > have to implement & deploy the same hack in every project ... Like I said, I object. If and when Texinfo makes it possible to seamlessly have several versions of the same manual on the same system, I will certainly reconsider (if I'm still around).