From: Pedro Alves <palves@redhat.com>
To: Mike Frysinger <vapier@gentoo.org>, Eli Zaretskii <eliz@gnu.org>
Cc: Joel Brobecker <brobecker@adacore.com>,
dje@google.com, gdb-patches@sourceware.org,
monaka@monami-software.com
Subject: Re: [doc] Avoid conflicts between gdb and cross-gdb.
Date: Thu, 21 Aug 2014 14:26:00 -0000 [thread overview]
Message-ID: <53F6018E.7020302@redhat.com> (raw)
In-Reply-To: <1554189.EX2Nlz1ClI@vapier>
On 08/08/2014 07:19 AM, Mike Frysinger wrote:
> On Thu 07 Aug 2014 18:43:34 Eli Zaretskii wrote:
>>> (1) Should we support out of the box distinct targets to be installed
>>> at the same prefix?
>>> (2) Should the name of some of those files match the name of
>>> the executable?
>>>
>>> For (1), I'm leaning towards a "not necessary", but we can perhaps
>>> find a middle ground. I don't know the various defaults to really
>>> help making a decision without spending some time to look at it.
>>> Either way, I have a fairly neutral opinion, so I am happy following
>>> the group.
>>>
>>> For (2), I thought that for the man page, and (to some degree, since
>>> I know little about info) the "info" page as well. But again,
>>> I don't really have much of opinion on that.
>>
>> But "info FOO" does not mean "show me the file FOO", it means "show me
>> the manual whose DIR entry is FOO". (Although the stand-alone Info
>> reader falls back to the file interpretation if it doesn't find FOO in
>> the DIR menu.)
>>
>> And the Info system doesn't really support more than one manual for
>> the same tool anyway.
>>
>> So I think, unlike the man pages, the Info manual should not be
>> renamed.
>
> yes, you'd actually have to rewrite the base node name so that instead of
> identifying itself as "gdb" it'd be "${target}-gdb" (i.e. apply the program
> transformation). then doing `info sh4-linux-gnu-gdb` would give you the
> correct man page. this matches the man page behavior where you can do `man
> sh4-linux-gnu-gdb` and such.
Eh, I always assumed this sort of thing is why we write @value{GDBN} all
over the manual, and that we were already transforming that, but indeed
seems like we aren't.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2014-08-21 14:26 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 [this message]
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
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=53F6018E.7020302@redhat.com \
--to=palves@redhat.com \
--cc=brobecker@adacore.com \
--cc=dje@google.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=monaka@monami-software.com \
--cc=vapier@gentoo.org \
/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