From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1795 invoked by alias); 15 Aug 2014 06:08: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 1783 invoked by uid 89); 15 Aug 2014 06:08:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 15 Aug 2014 06:08:39 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1XIAgl-00031T-TM from Yao_Qi@mentor.com ; Thu, 14 Aug 2014 23:08:35 -0700 Received: from SVR-ORW-FEM-06.mgc.mentorg.com ([147.34.97.120]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Aug 2014 23:08:35 -0700 Received: from qiyao.dyndns.org (147.34.91.1) by SVR-ORW-FEM-06.mgc.mentorg.com (147.34.97.120) with Microsoft SMTP Server id 14.2.247.3; Thu, 14 Aug 2014 23:08:34 -0700 Message-ID: <53EDA303.90701@codesourcery.com> Date: Fri, 15 Aug 2014 06:08:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Doug Evans CC: gdb-patches Subject: Re: [PATCH 0/3] Keep track of files copied to host and target References: <1408075184-25947-1-git-send-email-yao@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00270.txt.bz2 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. > 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. > > 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. 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. -- Yao (齐尧)