From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25929 invoked by alias); 23 Feb 2005 14:20:57 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 25879 invoked from network); 23 Feb 2005 14:20:49 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 23 Feb 2005 14:20:49 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j1NEKmvE009996 for ; Wed, 23 Feb 2005 09:20:48 -0500 Received: from pobox.surrey.redhat.com (pobox.surrey.redhat.com [172.16.10.17]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j1NEKmK03760; Wed, 23 Feb 2005 09:20:48 -0500 Received: from [172.31.0.98] (vpn83-133.boston.redhat.com [172.16.83.133]) by pobox.surrey.redhat.com (8.12.8/8.12.8) with ESMTP id j1NEKjMR022772; Wed, 23 Feb 2005 14:20:46 GMT Message-ID: <421C93D5.5080309@redhat.com> Date: Wed, 23 Feb 2005 16:11:00 -0000 From: Nick Clifton User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) MIME-Version: 1.0 To: "H. J. Lu" CC: binutils@sources.redhat.com Subject: Re: PATCH: Test the just built windres/dlltool only References: <20050218225935.GA30688@lucon.org> <20050218230100.GA28226@nevyn.them.org> <20050219024616.GA1429@lucon.org> <421A1E0B.4080306@redhat.com> <20050221174324.GA1042@lucon.org> <421B652F.9010202@redhat.com> <20050222233022.GA13476@lucon.org> In-Reply-To: <20050222233022.GA13476@lucon.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-02/txt/msg00556.txt.bz2 Hi H. J. >>But by this argument, your patch ought to be extended to all of the >>programs checked in the default.exp file, not just windres and dlltool. > windres and dlltool are only enabled for certain targets. It isn't > impossible that I have windres or dlltool in PATH for entirely > different purposes. I asked for windres nor dlltool not to be > built. It is kind of odd for "make check" to check my windres or > dlltool behind my back. I agree - especially if "make check" is going to check in-build-tree versions of the other commands. It certainly ought to be consistent, either checking all in-build-tree commands or all in-installed-tree commands. The point I was making was that your patch appeared to be treating windres and dlltool as special cases when really this ought to be an all or nothing approach as to which tools are tested. > But I don't think it is the best way to test the installed binutils. > Have you tried to test the installed binutils in the build directory? Err well I do not install binaries into a build directory, I install them into a completely separate directory. But I have tested installed binaries that were created from a build tree. (Usually because there is a bug in the install process somewhere and I want the testsuite to help me track down the problem). > Can you can show me how my patch prevents you from testing the > installed binutils? Sure, try this: * Build a mingw32-pe targeted toolchain (including gcc). * Install at least gcc and the binutils somewhere. * Go to the binutils build directory and run "make check". You will test the built executables in the build directory. Save the binutils.log for later comparison. * Then run "make clean" to get rid of the built executables and add the installed bin directory to your search path. Rerun "make check". You will test the installed executables using the build directory as a test framework. Save the binutils.log again. It should be essentially the same as the results from the in-build-tree test. * Now apply your patch to default.exp and rerun the "make check". This time the installed windres and dlltool will not be tested. Cheers Nick