From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20899 invoked by alias); 8 Aug 2014 02:53:08 -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 20875 invoked by uid 89); 8 Aug 2014 02:53:04 -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,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: smtp.gentoo.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 08 Aug 2014 02:53:02 +0000 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id AC54F3401AB; Fri, 8 Aug 2014 02:53:00 +0000 (UTC) From: Mike Frysinger To: Eli Zaretskii Cc: brobecker@adacore.com, gdb-patches@sourceware.org, monaka@monami-software.com Subject: Re: [doc] Avoid conflicts between gdb and cross-gdb. Date: Fri, 08 Aug 2014 02:53:00 -0000 Message-ID: <6996949.EeennEHWE2@vapier> User-Agent: KMail/4.13.3 (Linux/3.14.2; KDE/4.13.3; x86_64; ; ) In-Reply-To: <8338d8nvsc.fsf@gnu.org> References: <5772813.BLhj1dYueK@vapier> <8338d8nvsc.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8407070.V0dD68oxdg"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00159.txt.bz2 --nextPart8407070.V0dD68oxdg Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Content-length: 2237 On Thu 07 Aug 2014 18:50:43 Eli Zaretskii wrote: > > From: Mike Frysinger > > Cc: Joel Brobecker , gdb-patches@sourceware.org, > > monaka@monami-software.com Date: Wed, 06 Aug 2014 20:21:13 -0400 > >=20 > > > Besides, why do that? The Info manual does not include any > > > system-specific information, it is valid for all supported systems. > > > So I see no reason to put it into a system-dependent place or call it > > > by system-dependent name. > >=20 > > it's not system-dependent, but it is version dependent. reading the > > documentation for the native version can be wildly inaccurate than the > > documentation for the cross version. it's probably less of an issue for > > gdb as features/flags don't change wildly quickly, but it makes a huge > > difference for gcc (e.g. 4.7 to 4.8 to 4.9). >=20 > As I wrote elsewhere, Info doesn't support different versions of the > same manual installed on the same system, without some non-trivial > tinkering. i'm aware of the info indexing collisions. i deal with this with a lot of= =20 system packages in Gentoo. but a problem being hard doesn't mean we should= n't=20 try to make it work if it's the right thing to do ;). so the first question is, is this scenario important to us ? or do we=20 consider people dealing with cross-gdb's to be on their own and to figure o= ut=20 documentation skew problems themselves ? lumping it into the category of "= if=20 you're cross-compiling/debugging, you know what you're doing" doesn't fly a= s=20 there a _lot_ of people who do cross work and know very little here -- some= one=20 else is responsible for building/packaging the toolchain and they were just= =20 given it and told "use xxx-gcc and xxx-gdb". i think it's useful to have the full manual with the right version availabl= e=20 on a per-target basis, but maybe others here don't think it's useful enough= to=20 justify the work to make the info pages work. i.e. more of the ongoing=20 maintenance cost rather than just the initial up-front cost. maybe we can = get=20 assistance from the texinfo project to make this scenario easier so we don'= t=20 have to implement & deploy the same hack in every project ... -mike= --nextPart8407070.V0dD68oxdg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABAgAGBQJT5DuSAAoJEEFjO5/oN/WBsOMP/RkMpGiSON/2JU0vh5VXQ0fF G8xHsNjT/KArR44SY7md7/3utKP4RXGiCP1RgiWDjecTAufUAJKmAjqpcTNZ7q+q JLi1Mn64j5X+CDHfmuNvKJukSxdI0YBif0ZQJnYWk2lPODonPrtKPOKG9cSV71fu YJAYCbtsSGdKTi0Qlih+xPbgCwdgKExgf2zWTiEcSgH89vXv1vcVrFOmVoH1dMin i1ScCX/zJEEuc8QETUHLsXpWYEeFDm51rdN30TOsYDCk+d9iEKU0+zfHDP0vBbus 5RoJlxqW0qOx0iUcs+9FmJAsFZtJR6PSO71lg4hRN0RmWps2a6SsBLfRg86oTfF4 7sMQ9I8+1L2ldvwGDR7UKomuA1IIUlQNmuzg1lx7qfhPmV+PTcOX5h6ymTwoe6HV gS2JEAf9eIGZ9BZaSSrkdFBj1Qd/7hbKmLjskzAvP8T0mYxdVeZnedTniiQW8zOj 2KjMvtMF1yXCNa3lil/HHFPpbG6T/RrTOF8pn0ttjpPg6ypH9yI8nts08wpdM9y7 cY3ghu6w+TJo/CK0qYdL6VEHo6veFhMdRTwsZqzFXUSWOQ+M3t2DS2Tf4CZt5SvM GKDmGyyXsWKm3EyxVZ872Zc0YnLXBWlHiq128PKrwqtx8axHHxh+zmkiLwttozGx 6svCZB1oaFNVZMiM8+WS =T7rh -----END PGP SIGNATURE----- --nextPart8407070.V0dD68oxdg--