Kevin Oberman
2016-Dec-12 23:14 UTC
make buildkernel does not respect KERNCONF or JOBS in /etc/make.conf
On Mon, Dec 12, 2016 at 1:16 AM, tech-lists <tech-lists at zyxst.net> wrote:> On 12/12/2016 09:07, Thomas Mueller wrote: > >> My question is, do you build modules redundantly, or just once? >> I don't want to build the same modules more than once. >> > > For me - redundantly, I guess. It's not like it takes a lot of time or > space on the compiling machine, and I ensure that everything that needs to > be built, is built. > > PUMPKIN = heavily modified config with all the stuff I don't need stripped > out, and a couple of non-default lines. > > GENERIC = unmodified kernel that should work if by some chance PUMPKIN > doesn't. > -- > J.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. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman at gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Herbert J. Skuhra
2016-Dec-13 00:12 UTC
make buildkernel does not respect KERNCONF or JOBS in /etc/make.conf
Kevin Oberman skrev:> > On Mon, Dec 12, 2016 at 1:16 AM, tech-lists <tech-lists at zyxst.net> wrote: >> On 12/12/2016 09:07, Thomas Mueller wrote: >> >>> My question is, do you build modules redundantly, or just once? >>> I don't want to build the same modules more than once. >>> >> >> For me - redundantly, I guess. It's not like it takes a lot of time or >> space on the compiling machine, and I ensure that everything that needs to >> be built, is built. >> >> PUMPKIN = heavily modified config with all the stuff I don't need stripped >> out, and a couple of non-default lines. >> >> GENERIC = unmodified kernel that should work if by some chance PUMPKIN >> doesn't. >> -- >> J. > > > 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.??? From /usr/src/Makefile.inc1: 1137 .if ${TARGET_ARCH} == "powerpc64" 1138 KERNCONF?= GENERIC64 1139 .else 1140 KERNCONF?= GENERIC 1141 .endif [...] 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
Herbert J. Skuhra
2016-Dec-13 00:20 UTC
make buildkernel does not respect KERNCONF or JOBS in /etc/make.conf
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