From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13293 invoked by alias); 16 Aug 2014 00:38:43 -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 13168 invoked by uid 89); 16 Aug 2014 00:38:42 -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-f171.google.com Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com) (209.85.220.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 16 Aug 2014 00:38:38 +0000 Received: by mail-vc0-f171.google.com with SMTP id hq11so3709294vcb.16 for ; Fri, 15 Aug 2014 17:38:36 -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=jhb7U+xqMUplDtX3Ygb/F0A8VG41CaOB1rDs+7uz6Qw=; b=kU3zJ2J0xYc7tSg3+y2V7xRTX8+lrjcFQ5Gq8HbHR22tVfDJ+IyWPX0JlmtWpUEAZd Y/oYSaENxnMZdVCpjc7znhGspD4hdvU6zwNAMIkerL/o73Yr2gX5WZGnLLVvS48WSKv+ qvabJOjW0hsg3kXsxQ12RxBnRRv/VAg9s8rWP3TeUnPSpnfsj+fstCaj2Rm13hIIw074 Vkk04pk1aEtV3dJ5jQ8imVHCItP4STpHsvkO5wdZuzdKHfeP0xN9WxGb7RRMflKK+CoD hCKyqUjXnIEIUhtWYLpTBsdBgjWC5p0vFBVaxvSFb1lWeG1ZGpJtSQlGXX5OUPnUuOHn EPkg== X-Gm-Message-State: ALoCoQmRwSHC4MFMnrs59qtOIWuGMdVSvrehI5SByZwQ8xHQUKw3rrs/q6wAN9AFdMxvbi78kv3J MIME-Version: 1.0 X-Received: by 10.220.118.136 with SMTP id v8mr3641977vcq.50.1408149515866; Fri, 15 Aug 2014 17:38:35 -0700 (PDT) Received: by 10.52.136.203 with HTTP; Fri, 15 Aug 2014 17:38:35 -0700 (PDT) In-Reply-To: <53EDA303.90701@codesourcery.com> References: <1408075184-25947-1-git-send-email-yao@codesourcery.com> <53EDA303.90701@codesourcery.com> Date: Sat, 16 Aug 2014 00:38:00 -0000 Message-ID: Subject: Re: [PATCH 0/3] Keep track of files copied to host and target 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/msg00282.txt.bz2 On Thu, Aug 14, 2014 at 11:04 PM, Yao Qi wrote: > On 08/15/2014 01:00 PM, Doug Evans wrote: >> I hate to be a naysayer here, but I'm not convinced we should go down this path. >> > > This patch set is to make gdb testsuite follow the convention that copy > files to machine and remove them at the end. Nowadays, these files are > *.xml, *.py and file1.txt. This patch set releases test writers' > burden that manually removing copied files, so it becomes easier to > write tests. > > I don't know how this convention was made, but I'd like to follow it. We could instead have a convention that we just don't bother to clean up files downloaded to remote hosts. That's what's already done for the majority of files downloaded to remote hosts, so treating these files differently strikes me as unnecessary added complexity. Plus, when one is faced with having to debug a failure, one isn't hampered by having to refetch whatever files happened to get deleted. >> For one, I like files being left over after a test run. >> I would certainly object to cleaning up test binaries in native runs >> (at least without providing an easy way to not do that). I run "make >> check" and then manually play with the created binary *all the time*. >> I'm quite sure I'd feel the same way if I were doing Canadian Cross >> testing, or at least remote host testing. > > This patch set doesn't clean up binaries nor object files. It only > cleans up *.xml, *.py and file1.txt. These files can often also be required to debug failures. >> >> For another, I'd like to see a patch that cleans up all the other >> files (e.g., source files, object files, binaries) that dejagnu >> downloads as part of building the testcases. I could be missing >> something, this is based on my experiments and maybe I missed >> something. In my experiment, after "make check" had finished (at least >> I think it finished) there were ~1000 files in ~30MB left on the >> remote host. If the test didn't finish it may have been because I'd >> shutdown my machine too soon. :-) At any rate, it feels like what this >> patch set will clean up is a drop in the bucket compared to that. >> If we're not going to clean those up, I'd rather not complicate things >> further but only solving part of the problem (and a relatively far >> smaller part of the problem too). > > Yes, if we don't clean files up, patch #3 should be sufficient for the > problem I encountered. However, IMO, whether the existing convention > is good or bad, or do we want to move to "keep-everything" path, is > a separate topic and out of the scope of this patch set. Out of scope how? > Even we get consensus in the future, this patch set won't make any > troubles to us to go to any path. If we want to keep everything, we can > simply remove variable cleanfiles and its usages. If we want to delete > everything, we can add extra .c and .o files to cleanfiles. This patch > set is still useful. > >> >> Can we solve this problem differently perhaps? >> Is this just an appeal to some view of cleanliness, or is there a >> practical problem (running out of disk space or some such?) that the >> patch set is intended to solve? > > The patch set is intended to follow the existing convention of copying > and deleting files. Sure, but I'd like to get a better understanding of the technical reasons for doing so. There are technical reasons for not doing so (easier to debug failures, why add complexity that solves only a small portion of the entire problem).