Re: [PATCH 0/3] Keep track of files copied to host and target

[Doug Evans <dje at google dot com>]

On Thu, Aug 14, 2014 at 11:04 PM, Yao Qi <yao@codesourcery.com> 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).