From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11952 invoked by alias); 13 Aug 2014 03:09:20 -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 11935 invoked by uid 89); 13 Aug 2014 03:09:15 -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-f170.google.com Received: from mail-vc0-f170.google.com (HELO mail-vc0-f170.google.com) (209.85.220.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 13 Aug 2014 03:09:13 +0000 Received: by mail-vc0-f170.google.com with SMTP id lf12so14305962vcb.15 for ; Tue, 12 Aug 2014 20:09:10 -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=+uKTKfgql+aFC4JgzVp0AhzfcHFB94JJ4DORHDS3DME=; b=WQpGa7NgahAEUVbhWStsw2u8gUE6vNB+Hd7YRH1WaQ+P6YIjq8vEStPmfCOCf/SLPU w5H3C/29SObWEYdZdDCeBe2Nvs/sWswfLzSae1sS1yqiGpHBlkXFNVRsij3oW0bstBrR x2OyU+zfHyohmC1MiUwjco8buBA41fDH/R9cfhQ2WarF0yEChrMx6UeCy5uFAN7RqupG NlpaGKhqj5mNvSnSbxmcr4ZxINrBHE1yZY4p8LF7JbUzmfoLqs/rBZa+qx9EG7VOFYeT NDTXtQTaos8NiczFcCf/JXME1kwIw3xHNtW8nuy2JZf/n2kHiqt4xiQ126qMWwFQrQfr B1yQ== X-Gm-Message-State: ALoCoQkCmB3p4h/sDOEjOmZX3iUDI1C1tBymxTEva7hcuo6dAELQeTfCL2Pd6qUIqtIBG3uDWrVY MIME-Version: 1.0 X-Received: by 10.220.167.9 with SMTP id o9mr1372446vcy.8.1407899350492; Tue, 12 Aug 2014 20:09:10 -0700 (PDT) Received: by 10.52.136.203 with HTTP; Tue, 12 Aug 2014 20:09:10 -0700 (PDT) In-Reply-To: <53EAB6C4.40406@codesourcery.com> References: <1407849103-16521-1-git-send-email-yao@codesourcery.com> <21482.19388.251662.22760@ruffy.mtv.corp.google.com> <53EAB6C4.40406@codesourcery.com> Date: Wed, 13 Aug 2014 03:09:00 -0000 Message-ID: Subject: Re: [PATCH] Copy .py files to remote host From: Doug Evans To: Yao Qi Cc: gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00209.txt.bz2 On Tue, Aug 12, 2014 at 5:52 PM, Yao Qi 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.