From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lx7Az-0001DN-KK for qemu-devel@nongnu.org; Thu, 23 Apr 2009 18:13:49 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lx7Av-0001Ct-5D for qemu-devel@nongnu.org; Thu, 23 Apr 2009 18:13:49 -0400 Received: from [199.232.76.173] (port=33554 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lx7Au-0001Cq-UM for qemu-devel@nongnu.org; Thu, 23 Apr 2009 18:13:44 -0400 Received: from mx20.gnu.org ([199.232.41.8]:51933) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Lx7Au-0006EN-Ka for qemu-devel@nongnu.org; Thu, 23 Apr 2009 18:13:44 -0400 Received: from mail2.shareable.org ([80.68.89.115]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lx7Au-0000N8-0C for qemu-devel@nongnu.org; Thu, 23 Apr 2009 18:13:44 -0400 Date: Thu, 23 Apr 2009 23:13:34 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [7234] Use a more natural order Message-ID: <20090423221334.GO13326@shareable.org> References: <20090423185308.GH3795@csclub.uwaterloo.ca> <20090423191040.GI3795@csclub.uwaterloo.ca> <5d6222a80904231215p62c6594asc50230b252e892aa@mail.gmail.com> <49F0C826.4060503@codemonkey.ws> <20090423195902.GN3795@csclub.uwaterloo.ca> <49F0C9AA.1070703@codemonkey.ws> <20090423205431.GO3795@csclub.uwaterloo.ca> <49F0DA5A.8090400@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49F0DA5A.8090400@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Blue Swirl , Glauber Costa , qemu-devel@nongnu.org, Lennart Sorensen Anthony Liguori wrote: > >It might take 30 minutes, but it saves large amounts of time for everyone > >else later. Also I would hope make is smart enough to only recompile > >the bits that changed, so that shouldn't take as long. > > A great deal of our objects are target specific. Almost everything > depends on CONFIG_USER_ONLY too. This means that full compilation takes > a very long time. You might find ccache helps. For this kind of testing, nearly every compile should be a cache hit, so the slow part is limited running configure, make and preprocessing, and the final link. Just remember to clear out the cache when upgrading GCC :-) -- Jamie