From owner-cvs-src@FreeBSD.ORG Tue May 17 18:40:44 2005 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FB6016A4CE; Tue, 17 May 2005 18:40:44 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id D64D743DCA; Tue, 17 May 2005 18:40:43 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j4HIbFX7042311; Tue, 17 May 2005 12:37:15 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 17 May 2005 12:37:15 -0600 (MDT) Message-Id: <20050517.123715.74710629.imp@bsdimp.com> To: Alexander@Leidinger.net From: Warner Losh In-Reply-To: <20050517180454.brq1tjzo2s88g8ow@netchild.homeip.net> References: <20050517150415.cy3vhgx864kk8w8c@netchild.homeip.net> <86ekc5ubez.fsf@xps.des.no> <20050517180454.brq1tjzo2s88g8ow@netchild.homeip.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: des@des.no cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/ata ata-queue.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2005 18:40:44 -0000 From: Alexander Leidinger > And I haven't seen a technical reason why the classic way of doing it is bad. > Did I missed it or do I have to say "I don't get it"? It is better because it uses tools in your build tree, rather than what's installed on the system. For development, the classic way is as good as the new way. But for upgrades and such, you can get into lots of trouble when config or binutils, etc change. > >> If you just change one file and you want to recompile the kernel, which > >> procedure is faster? > > > > They're equally fast, though 'buildkernel' normally does 'make clean' > > and 'make depend' every time. Use NO_KERNELCLEAN when you can get > > away with it (which is most of the time; I have it in make.conf) and > > NO_KERNELDEPEND when you know you haven't changed the dependency tree > > (i.e. when you haven't changed any #include statements). All the > > usual tricks (KODIR, NO_MODULES, MODULES_OVERRIDE) also work. > > The "equally fast, though ..." part is funny (at least to me, YMMV)... > > So I have to type "make buildkernel -DNO_KERNELDEPEND" (while having > NO_KERNELCLEAN=yes in make.conf) instead of "make"... sorry, but I'm too > lazy to do this (at least as long as I don't get a benefit out of using the > new way). alias a "make buildkernel -DNO_KERNELDEPEND" Warner