Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: Eli Zaretskii <eliz@gnu.org>
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	[thread overview]
Message-ID: <6996949.EeennEHWE2@vapier> (raw)
In-Reply-To: <8338d8nvsc.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 2219 bytes --]

On Thu 07 Aug 2014 18:50:43 Eli Zaretskii wrote:
> > From: Mike Frysinger <vapier@gentoo.org>
> > Cc: Joel Brobecker <brobecker@adacore.com>, gdb-patches@sourceware.org,
> > monaka@monami-software.com Date: Wed, 06 Aug 2014 20:21:13 -0400
> > 
> > > 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.
> > 
> > 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).
> 
> 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 
system packages in Gentoo.  but a problem being hard doesn't mean we shouldn't 
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 
consider people dealing with cross-gdb's to be on their own and to figure out 
documentation skew problems themselves ?  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 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 ...
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2014-08-08  2:53 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-01  8:18 Masaki Muranaka
2014-08-01 15:07 ` Joel Brobecker
2014-08-02 12:58   ` Mike Frysinger
2014-08-06 13:24     ` Joel Brobecker
2014-08-06 17:05       ` Eli Zaretskii
2014-08-06 17:37         ` Joel Brobecker
2014-08-06 17:40           ` Eli Zaretskii
2014-08-06 19:53             ` Joel Brobecker
2014-08-06 20:05               ` Doug Evans
2014-08-06 21:34                 ` Joel Brobecker
2014-08-07 15:43                   ` Eli Zaretskii
2014-08-07 15:53                     ` Joel Brobecker
2014-08-08  6:19                     ` Mike Frysinger
2014-08-21 14:26                       ` Pedro Alves
2014-08-21 15:00                         ` Eli Zaretskii
2014-08-07  0:21         ` Mike Frysinger
2014-08-07 15:50           ` Eli Zaretskii
2014-08-08  2:53             ` Mike Frysinger [this message]
2014-08-08  6:05               ` Eli Zaretskii
2014-08-08  7:17                 ` Mike Frysinger
2014-08-21 14:30                   ` Pedro Alves
2014-08-06 22:55       ` Mike Frysinger

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=6996949.EeennEHWE2@vapier \
    --to=vapier@gentoo.org \
    --cc=brobecker@adacore.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=monaka@monami-software.com \
    /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