From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29714 invoked by alias); 27 Feb 2002 21:22:26 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 29629 invoked from network); 27 Feb 2002 21:22:17 -0000 Received: from unknown (HELO mel-rto1.wanadoo.fr) (193.252.19.188) by sources.redhat.com with SMTP; 27 Feb 2002 21:22:17 -0000 Received: from mel-rta9.wanadoo.fr (193.252.19.69) by mel-rto1.wanadoo.fr; 27 Feb 2002 22:22:16 +0100 Received: from acm.org (193.253.192.19) by mel-rta9.wanadoo.fr; 27 Feb 2002 22:22:06 +0100 Message-ID: <3C7D4DFC.8090208@acm.org> Date: Wed, 27 Feb 2002 14:43:00 -0000 From: Laurent Guerby User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205 X-Accept-Language: en-us MIME-Version: 1.0 To: Jim Wilson CC: Mark Mitchell , gcc@gcc.gnu.org Subject: Re: Installation proposal References: <11560000.1014832588@warlock.codesourcery.com> <3C7D2D69.8000107@acm.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-02/txt/msg01704.txt.bz2 Jim Wilson wrote: > If the install is overwriting /usr/bin/gcc, then it is a really good idea > to test it before installing it. I don't recommend doing builds that way, > but some people do. People installing a system compiler have probably their own install and test system (like recompiling the kernel, then checking the build of a few gigabytes of free software). We probably look like testing amateurs to them :). Who is seriously using configure with prefix /usr on a regular basis? > If you are building something to install in a location that you don't have > write access to, then you can still test it. Otherwise, you need to su root > first before you can test it. If our accepted target is location independance, then this argument is void. My own user policy is all root stuff is installed through binary packaging systems, everything else is installed with user permission (other solution I used where far worse :). The ACT GNAT install process is location independant and it does so by having a 10 line wrapper script that sets the needed env var and then call the real bin for all of its tools (using $0). > It makes the code-test-debug cycle faster, if you don't have to do an install > after writing code and before testing it. Full C+Ada install is 65s on my machine (boot is 47 minutes, check is 28 minutes, ACATS is 32 minutes). Doesn't look like a real argument. Plus as far as I can judge people code-test-debug on one test file (the bug) by using gdb on xx1, they don't run the full test suite after each one line change, they run it once it works reasonably on their test case, then bootstrap + check is going to take a while but install time is irrelevant then. > It also saves on disk space during the development cycle. With C+Ada install takes less space than a stage, and about 25% of a full make boostrap. If you are this short on space, then I don't even see how you can do any development work. > But yes, when you get to the point where you are making a release, it is > mandatory to test the installed compiler. And release are where we should be good on testing (easy to automate, testing what user will see). Why not use the same thing while developing? If we don't then all the trouble is for our loved release manager at release time :). > The current testsuites can be used > to test an installed compiler if there is no compiler in the build tree. Is this documented? (I remember only seeing "make -k check"). I would be *really* interested. -- Laurent Guerby