Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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