This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Copy .py files to remote host
- From: Doug Evans <dje at google dot com>
- To: Stan Shebs <stanshebs at earthlink dot net>
- Cc: Yao Qi <yao at codesourcery dot com>, gdb-patches <gdb-patches at sourceware dot org>
- Date: Tue, 12 Aug 2014 17:12:16 -0700
- Subject: Re: [PATCH] Copy .py files to remote host
- Authentication-results: sourceware.org; auth=none
- References: <1407849103-16521-1-git-send-email-yao at codesourcery dot com> <21482 dot 19388 dot 251662 dot 22760 at ruffy dot mtv dot corp dot google dot com> <53EAA9C3 dot 2090303 at earthlink dot 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.