Date: Thu, 26 Mar 2026 16:37:47 -0700 From: Mark Millard <marklmi@yahoo.com> To: Pat Maddox <pat@patmaddox.com> Cc: freebsd-pkgbase@freebsd.org Subject: Re: installing world from src on a pkgbase system Message-ID: <f4cf29f7-b216-41e2-80fe-5eaf3045623f@yahoo.com> In-Reply-To: <82e40b37-64b2-4dc2-b304-5002bacf4dc2@yahoo.com> References: <UGVbTfxFnLh7zkFaMJrCf_Fll6DjeBxw5VK_kc_jdLlOlJPe6QtfNOQm23v-DOSO-DP1YiEcP8APpn9To22Lc64V-oX24Mor7jSE_ZtYmj8=@proton.me> <acRQcjyIZ_Krfyw4@amaryllis.le-fay.org> <m-cS1PTzow3fGVjDOpYyn6W_o4S1wWeW_rAts1LiWRgqkb4CXug6y8weHusL07G9vt2l5WGX76OF2C-JckHufUvwSqJ4511_3wNZ81QeOz4=@proton.me> <acRZ6iRoJPgZUFmt@amaryllis.le-fay.org> <pcRls0mXL2DAbxhH0bMX_DPGdlHbwm8fNM9fEAJXVBZgoqxfP1mCHAA9wsCDbvl9AeV4_BNhd3UZqCpBtLgMI59ZirMmwsLNsLeVmoVY__0=@proton.me> <be4dc8f9-84b7-456f-8f64-d09488be3dc6@yahoo.com> <0802ab25-0509-44d1-929e-2bb81108fa38@app.fastmail.com> <82e40b37-64b2-4dc2-b304-5002bacf4dc2@yahoo.com>
index | next in thread | previous in thread | raw e-mail
On 3/26/26 13:59, Mark Millard wrote: > On 3/26/26 12:05, Pat Maddox wrote: >> On Thu, Mar 26, 2026, at 9:52 AM, Mark Millard wrote: >>> On 3/26/26 04:30, polyduekes@proton.me wrote: >>>> On Thursday, March 26th, 2026 at 3:26 AM, Lexi Winter <ivy@freebsd.org> wrote: >>>> >>>>> polyduekes@proton.me wrote in <m-cS1PTzow3fGVjDOpYyn6W_o4S1wWeW_rAts1LiWRgqkb4CXug6y8weHusL07G9vt2l5WGX76OF2C-JckHufUvwSqJ4511_3wNZ81QeOz4=@proton.me>: >>>>>> is needing to do both buildworld and buildkernel to create a pkg repo >>>>>> the intended behaviour or is that planned to change >>>>> >>>>> right now i don't believe there are any plans to change that. i suppose >>>>> it might change in the future. usually people want to build both the >>>>> world and the kernel, so this isn't an oft-requested feature. >>>>> >>>>> could you elaborate on why you want to build world but not kernel? >>>>> this would help inform development efforts in that area. >>>>> >>>> i usually make my own changes to base code to test some things and learn a few others,and most of the time the changes i make touch only world and dont touch kernel at all,so i like to avoid unnecessary compilation of the binaries and things i didn't change and doing only make buildworld and not make buildkernel buildworld is part of that reason >>> >>> Are you aware of META_MODE for buildworld and buildkernel (with its use >>> of filemon.ko)? Its purpose is to keep track of things and so generally >>> rebuild what is necessary but avoid rebuilding what is not. For example, >>> back to back rebuilds have the second one not taking very long based on >>> the lack of changes. >> >> How long is "not very long" in your experience? > > I happen to have been doing builds as part of a long overdue update of > my context. The below builds were executed from an official pkgbase > distribution of main that was booted, using the non-debug kernel that > was distributed. (Only a debug world is distributed for main.) But I was > building non-debug worlds and kernels of nearly the same source code, > with other tailoring involved, such as static linking of the llvm > related toolchain. > > I've access to a wide range of system performance, from old armv7 RPi*'s > to a 7950X3D amd64 system with Optane 1.4T media on PCIe. > > First picking an aarch64 system likely slow compared to common amd64 > hardware, but faster than a RP* aarch64 system, showing both > from-scratch build time and then the rebuild, not having changed > anything, showing both World and Kernel. . . > > Microsoft Dev Kit 2023 from-scratch build sequence, USB3 based media, 8 > core, 32 GiByTes of RAM: (I have reordered lines to have the world's > together and the kernels together and used extra end-of-lines to group > things and some leading spaces to avoid misformatting) > > # grep "built.*ncpu:" > /usr/obj/BUILDs/main-CA76-nodbg-clang/sys-typescripts/typescript-make-main-*.2026-03-2[56]* > > /usr/obj/BUILDs/main-CA76-nodbg-clang/sys-typescripts/typescript-make-main-CA76-nodbg-clang.aarch64-host.2026-03-25:23:12:00: > >>> World built in 10909 seconds, ncpu: 8, make -j12 > /usr/obj/BUILDs/main-CA76-nodbg-clang/sys-typescripts/typescript-make-main-CA76-nodbg-clang.aarch64-host.2026-03-26:13:04:35: > >>> World built in 146 seconds, ncpu: 8, make -j12 > > /usr/obj/BUILDs/main-CA76-nodbg-clang/sys-typescripts/typescript-make-main-CA76-nodbg-clang.aarch64-host.2026-03-26:02:13:50: > >>> Kernel(s) GENERIC-NODBG-CA76 built in 632 seconds, ncpu: 8, make -j12 > /usr/obj/BUILDs/main-CA76-nodbg-clang/sys-typescripts/typescript-make-main-CA76-nodbg-clang.aarch64-host.2026-03-26:13:07:02: > >>> Kernel(s) GENERIC-NODBG-CA76 built in 11 seconds, ncpu: 8, make -j12 > > > A faster system . . . > > amd64 7950X3D with Optane 1.4T media on PCIe, 32 freebsd CPUs (16 SMT > cores);, 192 GiBytes of RAM: > > # grep 'built.*ncpu:' > /usr/obj/BUILDs/main-ZNV4-*-clang/sys-typescripts/typescript-make-ZNV4-*-clang-amd64-host-2026-03-2[56]* > > /usr/obj/BUILDs/main-ZNV4-nodbg-clang/sys-typescripts/typescript-make-ZNV4-nodbg-clang-amd64-host-2026-03-25:15:50:07: > >>> World built in 1048 seconds, ncpu: 32, make -j48 > /usr/obj/BUILDs/main-ZNV4-nodbg-clang/sys-typescripts/typescript-make-ZNV4-nodbg-clang-amd64-host-2026-03-26:13:10:20: > >>> World built in 34 seconds, ncpu: 32, make -j48 > > /usr/obj/BUILDs/main-ZNV4-nodbg-clang/sys-typescripts/typescript-make-ZNV4-nodbg-clang-amd64-host-2026-03-25:15:47:41: > >>> Kernel(s) GENERIC-NODBG built in 91 seconds, ncpu: 32, make -j48 > /usr/obj/BUILDs/main-ZNV4-nodbg-clang/sys-typescripts/typescript-make-ZNV4-nodbg-clang-amd64-host-2026-03-26:13:10:54: > >>> Kernel(s) GENERIC-NODBG built in 2 seconds, ncpu: 32, make -j48 > > > So the example ratios span: > 10909/146 approx.= 74.7 > 1048/34 approx.= 30.8 I should have pointed out that back-to-back builds (no changes) have the 2nd build being about as fast as it can get: otherwise changes lead to more being rebuilt. Even back to back builds [no changes] do some build/linking activity. It is difficult to make everything perfectly minimal while always rebuilding when it is important. For some aspects there are tradeoffs for false positive vs. false negative handling for things not likely to actually need a rebuild. For the most part, where possible, the bias has been for uncertainty to lead to some rebuild activity that might not have been necessary --instead of having potential broken builds. An example context is: buildworld reboot installworld reboot buildworld The install activity leads to more rebuild activity later --from the install updating programs (and other files) to be technically newer than they were during the prior buildworld, despite lack of changes in those files that might be relevant to worrying about the program results being different for the use in the build sequence. For example, if echo contributed to a file's content (say, via >> use), how likely is it that an updated echo's output would be any different for that file in the rebuild? Arbitrary changes touching common usage results is unlikely for something like echo at this point. > > I'll not get into the details of my builds. The builds are personal > builds in various ways. > >> >> Pat >> >> > > Note: I'm not set up to send to freebsd-questions. > -- === Mark Millard marklmi at yahoo.comhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f4cf29f7-b216-41e2-80fe-5eaf3045623f>