Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 May 2005 12:37:15 -0600 (MDT)
From:      Warner Losh <imp@bsdimp.com>
To:        Alexander@Leidinger.net
Cc:        cvs-src@FreeBSD.org
Subject:   Re: cvs commit: src/sys/dev/ata ata-queue.c
Message-ID:  <20050517.123715.74710629.imp@bsdimp.com>
In-Reply-To: <20050517180454.brq1tjzo2s88g8ow@netchild.homeip.net>
References:  <20050517150415.cy3vhgx864kk8w8c@netchild.homeip.net> <86ekc5ubez.fsf@xps.des.no> <20050517180454.brq1tjzo2s88g8ow@netchild.homeip.net>

next in thread | previous in thread | raw e-mail | index | archive | help
From: Alexander Leidinger <Alexander@Leidinger.net>
> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050517.123715.74710629.imp>