From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 511 invoked by alias); 13 Aug 2014 00:12:24 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 495 invoked by uid 89); 13 Aug 2014 00:12:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-vc0-f172.google.com Received: from mail-vc0-f172.google.com (HELO mail-vc0-f172.google.com) (209.85.220.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 13 Aug 2014 00:12:19 +0000 Received: by mail-vc0-f172.google.com with SMTP id im17so14223251vcb.31 for ; Tue, 12 Aug 2014 17:12:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=l6HMR6uFRYyILRhmTyg9A/K6HcXpi4c7/9gsSyi42Ho=; b=CXyHywyIbJO/ofPdB5p69oYeVqQ8OMH1pSSWKElluw+8Fcl81wVYkwW/2skCJDIarL WhI+1zhfgp5M1b3nK4HKbWC2UEFG0s0lKvJVMlH1EzZR8GNFvNsinnadrVTSsMH2qjHi ThxP4mSuE80paY4VqrkXGKKlL/zuxbTlUfHG6RgsLHhsvuhxQypq5at2gSG77CLf0oq8 hSQJ2gfHq3ig8XjfWRTL+0xZZ33HhNfsmxwCUvOFt+AZzsh8sveyx5fDt+htdjpK8gxN x5UPYaHkFhUHJ8xCfKVsie+6f+xMcp3B7RdlJBcV2ldn+Hb/8/8Hd6D6NfLd64zRiFez BeYA== X-Gm-Message-State: ALoCoQlpTbWVw4dfQGyhK6n3Mur6nWWFcIpTyAYqDtkTnrnHMLtm7CBWlh2r4XrH4miLsM7NPJSA MIME-Version: 1.0 X-Received: by 10.221.21.201 with SMTP id qt9mr670907vcb.39.1407888736710; Tue, 12 Aug 2014 17:12:16 -0700 (PDT) Received: by 10.52.136.203 with HTTP; Tue, 12 Aug 2014 17:12:16 -0700 (PDT) In-Reply-To: <53EAA9C3.2090303@earthlink.net> References: <1407849103-16521-1-git-send-email-yao@codesourcery.com> <21482.19388.251662.22760@ruffy.mtv.corp.google.com> <53EAA9C3.2090303@earthlink.net> Date: Wed, 13 Aug 2014 00:12:00 -0000 Message-ID: Subject: Re: [PATCH] Copy .py files to remote host From: Doug Evans To: Stan Shebs Cc: Yao Qi , gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00205.txt.bz2 On Tue, Aug 12, 2014 at 4:56 PM, Stan Shebs 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.