Re: [doc] Avoid conflicts between gdb and cross-gdb.

[Mike Frysinger <vapier at gentoo dot org>]

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: signature.asc
Description: This is a digitally signed message part.