From owner-freebsd-stable@freebsd.org Tue Dec 13 17:03:04 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83958C759A0 for ; Tue, 13 Dec 2016 17:03:04 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1D4B91614 for ; Tue, 13 Dec 2016 17:03:03 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: febba704-c155-11e6-9673-39b5816e8152 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id febba704-c155-11e6-9673-39b5816e8152; Tue, 13 Dec 2016 17:02:58 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id uBDH2nUg001457; Tue, 13 Dec 2016 10:02:49 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1481648569.1889.333.camel@freebsd.org> Subject: Re: make buildkernel does not respect KERNCONF or JOBS in /etc/make.conf From: Ian Lepore To: Kevin Oberman , "Herbert J. Skuhra" Cc: FreeBSD-STABLE Mailing List Date: Tue, 13 Dec 2016 10:02:49 -0700 In-Reply-To: References: <201612120138.uBC1cA59025994@sdf.org> <86r35dd46x.wl-herbert@mailbox.org> <9B.7B.16304.3F86E485@dnvrco-omsmta02> <15672f53-1a34-3120-0aa8-03aa6401be54@zyxst.net> <86pokwptmd.wl-herbert@mailbox.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 17:03:04 -0000 On Mon, 2016-12-12 at 20:22 -0800, Kevin Oberman wrote: > On Mon, Dec 12, 2016 at 4:20 PM, Herbert J. Skuhra rg> > wrote: > > > > > Kevin Oberman skrev: > > > > > > > > > Clearly the documentation is a bit behind the times. For some > > > time people > > > have used KERNCONF to build multiple kernels, but that was a > > > lucky things > > > that was not officially supported. It just happened to work. > > > Then, with > > > 11.0, it no longer did in many cases sue to changes in the kernel > > > build > > > system. When people complained, there did not seem to be a way to > > > fix > > this > > > > > > without blocking future goals in speeding up and enhancinghte > > > standard > > > kernel build. > > > > > > The result was BUILDKERNELS. It was specifically designed to > > > allow the > > > building of multiple kernels and the appropriate modules. This > > > would > > always > > > > > > take longer and use more disk space, but it would work reliably. > > > Now, bit > > > building a single, local kernel, KERNCONF is the best way, though > > > I > > suspect > > > > > > that it make only a small difference until new capabilities are > > > added > > later > > > > > > in the life of 11. > > > > > > So, while it seems the man pages need to catch up, building > > > multiple > > > kernels should be done with KERNCONF in either make.conf or > > > src.conf and > > > multiple kernels with BUILDKERNELS. > > > > > > This is from my recollection of the discussion thread. I'll admit > > > to > > being > > > > > > too lazy to go find and read all of it. I suspect it was on > > > current@, > > but > > > > > > I'm not even sure of that. > > ??? > > > > From /usr/src/Makefile.inc1: > > > >    1137 .if ${TARGET_ARCH} == "powerpc64" > >    1138 KERNCONF?=      GENERIC64 > >    1139 .else > >    1140 KERNCONF?=      GENERIC > >    1141 .endif > >    [...] > >    1149 BUILDKERNELS= > >    1150 INSTALLKERNEL= > >    1151 .if defined(NO_INSTALLKERNEL) > >    1152 # All of the BUILDKERNELS loops start at index 1. > >    1153 BUILDKERNELS+= dummy > >    1154 .endif > >    1155 .for _kernel in ${KERNCONF} > >    1156 .if exists(${KERNCONFDIR}/${_kernel}) > >    1157 BUILDKERNELS+=  ${_kernel} > >    1158 .if empty(INSTALLKERNEL) && !defined(NO_INSTALLKERNEL) > >    1159 INSTALLKERNEL= ${_kernel} > >    1160 .endif > >    1161 .endif > >    1162 .endfor > > > > So setting BUILDKERNELS has no effect. > > > > -- > > Herbert > > > I think you miss the significance. BUILDKERNELS only is used to build > the > kernels. It is not used by installkernel as installing two kernels > does not > make sense. It is ONLY used to build multiple kernels. KERNCONF is > still > used to specify the kernel, with attendant modules, to be installed. > > I should also mention that, if you want to install a new kernel > without > overwriting the old kernel and modules (/boot/kernel.old/), "make > reinstallkernel". It replaces the existing kernel instead of renaming > the > kernel directory to kernel.old. I find this very handy, but it is > poorly > documented. So, if you want to install GENERIC and not lose your last > working kernel, "make reinstallkernel KERNCONF=GENERIC". That will > blow > away the bad kernel and modules and install GENERIC. Note that it > does not > touch the /usr/obj directory that PUMPKIN is built in, so PUMPKIN and > similarly be reinstalled. > > The man page for src.conf is automatically generated and only lists > those > values which are specific to src.conf (WITH_ and WITHOUT_) and > describes > its use. It is used as input for system builds and installs but > should not > be accessed for any other purpose. make.conf is always read by make > with no > regard to what is being made. (N.B. I believe that some people have > ignored > this in some ports stuff.) Anything that is put into make.conf may be > placed in src,conf if you only want to have it used when > building/installing the kernel and world. > > I'm probably forgetting something, but I hope this explains it a bit. The BUILDKERNELS variable is part of the build system's internal machinery for building multiple kernels when the user has set KERNCONF= to more than one name.  It's not a thing that a user can set. -- Ian