From: Pedro Alves <palves@redhat.com>
To: Yao Qi <yao@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC] new board file 'remote-host-native.exp'
Date: Wed, 25 Jul 2012 13:48:00 -0000 [thread overview]
Message-ID: <500FF91C.9030009@redhat.com> (raw)
In-Reply-To: <1804874.ivBX2v1I8f@qiyao.dyndns.org>
On 07/25/2012 08:27 AM, Yao Qi wrote:
> On Tuesday, July 24, 2012 05:08:26 PM Pedro Alves wrote:
>> Why natively? I'd think you could use both this host board with e.g.,
>> a gdbserver target board file. I suggest:
>>
>> +# This file is a dejagnu "board file" and is used to run the testsuite
>> +# against local host, in remote host mode.
>>
>> I'd even rename the file to local-remote-host.exp.
>>
>
> Looks term "native" can be used for target board file, while term
> "local/remote" can be used for host board file. Comment is fixed.
> I thought of 'local-remote-host.exp' before, but gave it up since I
> was afraid people are confused by its name. I am fine with it.
If nobody complains, let's run with it.
>>> +set_board_info username YOUR.USER.NAME
>>
>> We can make this pick up the current user by default on at least GNU/Linux,
>> and probably other Unixen:
>>
>> set_board_info username $::env(USER)
>>
>
> What does these double colons mean? I use $env(USER), and it works fine.
Ah, I just basically copy/pasted from <http://wiki.tcl.tk/1624> :
"To access the env array within a Tcl proc, one needs to tell the proc that env is a global array. There are two ways to do this.
$::env(PATH)
global env ; puts $env(PATH) can alternatively used to identify that the variable is
globally available; however, you have to remember to use the global command
in EVERY proc that you need to use env. Using the $::env notation is shorter."
Since this is global code anyway (not within a proc) $env should be fine (and is the
style used elsewhere). Go ahead and make that change.
It's true, most of my tcl foo is web search based. :-)
> Yes, with ${board}_download, files are not copied to somewhere else through
> ssh, so the test is faster. One line of comment is added. How about the
> new one?
Looks fine to me. Thanks!
--
Pedro Alves
next prev parent reply other threads:[~2012-07-25 13:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-24 13:10 Yao Qi
2012-07-24 16:08 ` Pedro Alves
2012-07-25 7:27 ` Yao Qi
2012-07-25 13:48 ` Pedro Alves [this message]
2012-08-02 8:47 ` [committed]: " Yao Qi
2012-07-25 22:45 ` Stan Shebs
2012-07-26 1:45 ` Yao Qi
2012-08-02 8:50 ` Doug Evans
2012-08-02 8:53 ` Doug Evans
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=500FF91C.9030009@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=yao@codesourcery.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