From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28694 invoked by alias); 18 Aug 2004 22:03:23 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 28675 invoked from network); 18 Aug 2004 22:03:21 -0000 Received: from unknown (HELO burundai.radix50.net) (82.83.205.69) by sourceware.org with SMTP; 18 Aug 2004 22:03:21 -0000 Received: from burundai.radix50.net (localhost [127.0.0.1]) by burundai.radix50.net (8.12.3/8.12.3/Debian -4) with ESMTP id i7IM6Fvh004100 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Thu, 19 Aug 2004 00:06:16 +0200 Received: (from ibr@localhost) by burundai.radix50.net (8.12.3/8.12.3/Debian -4) id i7IM6D72004099 for gdb-patches@sources.redhat.com; Thu, 19 Aug 2004 00:06:13 +0200 Date: Wed, 18 Aug 2004 22:03:00 -0000 From: Baurjan Ismagulov To: gdb-patches@sources.redhat.com Subject: Re: testcase for "absolute source" patch Message-ID: <20040818220613.GA3143@ata.cs.hun.edu.tr> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20040816144349.GB1509@ata.cs.hun.edu.tr> <412107B7.nailE7I1XJVIH@mindspring.com> <20040818130626.GB1411@ata.cs.hun.edu.tr> <4123763C.nailM3P11DT7E@mindspring.com> <20040818155324.GC1411@ata.cs.hun.edu.tr> <4123A736.nail5OO17XN7L@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4123A736.nail5OO17XN7L@mindspring.com> User-Agent: Mutt/1.5.6+20040523i X-SW-Source: 2004-08/txt/msg00569.txt.bz2 Hello Michael, On Wed, Aug 18, 2004 at 03:00:06PM -0400, Michael Chastain wrote: > The problem is default_target_compile in dejagnu. > default_target_compile really wants to be in charge of downloading files > from build to host and managing the filenames on the host. This > directly conflicts with your script, which wants to manage the names > on the host. As far as I could understand, there are also other tests that do not work well in build != host scenario. I don't remember any decision from the recent thread on this issue. OTOH, this test functions locally and checks a number of cases, at least two of which have been subject to regressions. I think this was the reason why Andrew asked for it in the first place. While I agree that fixing the infrastructure is also important, may I suggest that we have at least local checking in the trunk? After all, whatever the state of the infrastructure, we still want to check for bugs; a non-ideal test is better than no test at all, IMHO. I also don't see any problem in modifying the test as the infrastructure changes, whereas not having the test is going to lead to bugs, especially given an open PR involving the respective subsystem. To summarize: the test is working probably for 95% of the users. I'm willing to make the test as close to the ideal in your head as possible, and I can do it only now. I suggest that we improve what can be improved and leave the rest for better times. What do you think? With kind regards, Baurjan.