Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Doug Evans <dje@google.com>
To: Stan Shebs <stanshebs@earthlink.net>
Cc: Yao Qi <yao@codesourcery.com>, gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Copy .py files to remote host
Date: Wed, 13 Aug 2014 00:12:00 -0000	[thread overview]
Message-ID: <CADPb22RNLtNsNGSRsSaZ4XVLSDgdSTqraeqK5tV3fv3BRPWM6Q@mail.gmail.com> (raw)
In-Reply-To: <53EAA9C3.2090303@earthlink.net>

On Tue, Aug 12, 2014 at 4:56 PM, Stan Shebs <stanshebs@earthlink.net> wrote:
> On 8/12/14, 10: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?
>
> Going by instances of remote_file delete in the testsuite,
> it's at least semi-standard to do so.  It certainly reduces
> the chances of confusion for any functionality that is based
> on searching for a matching file to load/process.

It's a bit odd though to do this cleanup both in tcl and in "make clean".
I realize "make clean" won't remove remote files :-),
but there's still this weirdness of some files cleaned up by tcl
and some cleaned up by make.

It would be interesting to see some real data.
How hard would it be to start with a fresh build,
and do "ls -R" before/after a full testsuite run on a remote host.
IOW, what *are* the files that we're leaving behind on the remote host?
[I can do it, but I'm guessing someone already has a tree that is set up.]

>> 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?
>
> I could go for that.  The existing deletions seem to be in a variety
> of styles, and it would be useful to have standard failure handling
> and such.

Not only just having a standard, but saving having to remember
and fill every test exit point with special code.


  reply	other threads:[~2014-08-13  0:12 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 [this message]
2014-08-13 10:28     ` Doug Evans
2014-08-13  0:56   ` Yao Qi
2014-08-13  3:09     ` Doug Evans
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=CADPb22RNLtNsNGSRsSaZ4XVLSDgdSTqraeqK5tV3fv3BRPWM6Q@mail.gmail.com \
    --to=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=stanshebs@earthlink.net \
    --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