From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19240 invoked by alias); 18 Aug 2004 22:46:18 -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 19225 invoked from network); 18 Aug 2004 22:46:16 -0000 Received: from unknown (HELO smtp6.mindspring.com) (207.69.200.110) by sourceware.org with SMTP; 18 Aug 2004 22:46:16 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by smtp6.mindspring.com with esmtp (Exim 3.33 #1) id 1BxZC4-0003Ht-00; Wed, 18 Aug 2004 18:46:08 -0400 Received: from mindspring.com (localhost [127.0.0.1]) by berman.michael-chastain.com (Postfix) with SMTP id AA9F04B102; Wed, 18 Aug 2004 18:46:15 -0400 (EDT) Date: Wed, 18 Aug 2004 22:46:00 -0000 From: Michael Chastain To: ibr@ata.cs.hun.edu.tr, gdb-patches@sources.redhat.com Subject: Re: testcase for "absolute source" patch Message-ID: <4123DC37.nail63S11B327@mindspring.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> <20040818220613.GA3143@ata.cs.hun.edu.tr> In-Reply-To: <20040818220613.GA3143@ata.cs.hun.edu.tr> User-Agent: nail 10.8 6/28/04 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg00570.txt.bz2 Baurjan Ismagulov wrote: > I don't remember any decision from the recent thread on this issue. That's true. The last time I posted about it, I was leaning towards requiring that build != host work, partly because Dan Kegel's documentation on testing cross-gcc explicitly describes how to set up build != host, and partly because Felix Lee stepped up and said that he had used it in the past. But I failed to announce a decision. "leaning towards" is not really a decision. > As far as I could understand, there are also other tests that do not > work well in build != host scenario. And that's also true. I posted a list of 11 test scripts that don't work with build != host because they neglect to download their .h files. There are probably others that fail for other reasons as well. > While I agree that fixing the infrastructure is also important, may I > suggest that we have at least local checking in the trunk? I'm going to reject that argument. I don't want the test suite to add more stuff that runs in some conditions but not others. That becomes a source of unending maintenance work. To me, a flawed test *is* sometimes worse than no test at all, because then I have to maintain it. I would rather have more time (and more of other people's time) actually running the test suite, reporting the results, analyzing the failures, and creating good PR's, rather than adding test scripts that don't work in some supported environments. As long as we have a "build != host" requirement, I won't accept any scripts that obviously won't run in that environment. I'm still open to killing that requirement. You've exhibited a test script that (a) is useful and (b) has a hard time meeting that requirement. That balances against the usefulness of keeping build != host. Michael