Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Doug Evans <dje@google.com>
To: Yao Qi <yao@codesourcery.com>
Cc: gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Copy .py files to remote host
Date: Wed, 13 Aug 2014 03:09:00 -0000	[thread overview]
Message-ID: <CADPb22TN7qPfFWb36JmUAMPFhEvjF=+FDM09pNo2w_om1N0S-A@mail.gmail.com> (raw)
In-Reply-To: <53EAB6C4.40406@codesourcery.com>

On Tue, Aug 12, 2014 at 5:52 PM, Yao Qi <yao@codesourcery.com> wrote:
> On 08/13/2014 01:15 AM, Doug Evans wrote:
>> I still have an outstanding question on this topic,
>> and before this gets checked in I'd like to get it resolved.
>> Do we delete other files downloaded to the remote target?
>
> Yes, at least shared libs downloaded to target are cleaned up.
> In lib/gdb.exp, there is a list cleanfiles, to record the files
> downloaded to target, and in gdb_finish, remove files in this list.

Yeah, we keep track of files downloaded to the target.
Can we do something similar for the host?

>>
>> At one point I tried to find a place there the testsuite code was
>> taking care to delete other downloaded files, but couldn't.
>> Since we've gotten by this long without doing so
>> [and this is *still* just a hypothesis - I haven't worked with
>> remote hosts in awhile ...]
>> I would rather just punt on deleting python files as well,
>> and document that that is the convention (since for every other
>> file it already is :-)).
>> [Why treat python files differently?]
>
> Where can we document this convention? gdb/testsuite/README?  I can't
> find a proper one.  Existing test cases are good documentation to me,
> and people usually follow the existing tests when they create new ones.

I think gdb/testsuite/README is fine.

>>
>> If we really did want to fully clean up after each test,
>> and we should first establish that that is indeed what we want to do,
>> instead of filling every test exit point with explicit code to delete
>> only one kind of downloaded file, how about instead keep a list of all
>> downloaded files and call a routine to delete the files in that list
>> from some central cleanup point?
>
> Yeah, I also dislike writing "remote_file host delete $FOO" at the each
> test exit point explicitly.  Not sure what do you want in "fully clean
> up", but at least, we can clean up python files as you said.

If we keep track of files downloaded to the host like we do for the
target, it seems like this would be enough.


  reply	other threads:[~2014-08-13  3:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-12 13:15 Yao Qi
2014-08-12 17:15 ` Doug Evans
2014-08-12 23:57   ` Stan Shebs
2014-08-13  0:12     ` Doug Evans
2014-08-13 10:28     ` Doug Evans
2014-08-13  0:56   ` Yao Qi
2014-08-13  3:09     ` Doug Evans [this message]
2014-08-13  5:50       ` Doug Evans
2014-08-13  5:52         ` 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='CADPb22TN7qPfFWb36JmUAMPFhEvjF=+FDM09pNo2w_om1N0S-A@mail.gmail.com' \
    --to=dje@google.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