This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> From: Mike Frysinger <vapier@gentoo.org>
> 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).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]