From nobody Tue May 6 19:16:07 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZsSmp18wMz5vH8x for ; Tue, 06 May 2025 19:16:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZsSmn4wZZz3dfv for ; Tue, 06 May 2025 19:16:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1746558983; bh=AFjcyuto1ePmbCRo2nNn+mYeQgADfSGj7Kk7EwqcuKQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=VpOO+nS5XNlbvVQlpBaDX6qwwIHUiOiHDJx2+8r5XsIBvL4nhAESya/BaZ466Z3QGNyA810JcJ+fgxyN5EM++lpUskbCYC0nx+HBYd5yb6IYhdMnjA04HLM/r6M6QoJK4vwRsmBDGeX6RVNUSFsXiqnSJ8PrnWTdL66eRg3fCfGSTgls9+zb2dTsE5P7XQ57nQVEgnZ7PlKZUPPVtXlgJmTOmYNJMyCkVLIFUY+YVbh5BaGCVO+ERYFkU0Iiv9rk7BFoLorBJOdw6Jw7GWjmIhOSF+1uE45/ZgQPXLKETzdZK7bjtp1nuVIhfq6zNfnGV4teG0IHfH2gGDX6KYCMiA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1746558983; bh=iXJvg7v1KR+bs5lD3icys/LyeSq2yqrIskC3/uOfPtz=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=JZHb4K3bMrxbMaLq6Y7Dg8aEZYUscLbDK5/1MOEH4i7GaTW50FmuKz2Hu4gTvEyi6vrVZUML2/oFhz7aS7w2a5xIPF1COXTFSqBMnpqOJH2SHBN610vQ02LfKqZBtxTUfiVFAAIUEeeohiPpFVPMChzHTm83W5D56o+4r7nTX/ZKm4Ft4LW6FCye6dABwixzMMyFmKubQwihU2d5qIIjj5ZDZPIVSbXxGhL+IBxt0e66AXVyRlabVC4wA4/Rfq1N5DZEJbhnwRu8OSV5ZvepoAg3BkqLtg8zs3cEzpw4WaIC9jBbfN/Vx55px/wbIlk35BSXERCwddrWEPJcWmfYxg== X-YMail-OSG: lYD53qoVM1mGGokGc51GJlo_j4gyZpNNHLbaOlyXrkKtKXUkSk_APw5K5SL.de0 NiiFfQywp1Zmt57hMCWbJ98T35y1l0ssy4VLjmqvxEizqAgKnShG.z2ZZ8a4S3fS.7SMZknzHSF_ A1Qw.BD3s2Lom4JBPdpWHRytFjDSMUDLv5WdMT1V9sbria13blYA8Y7aXTtrqnREQQ_CQ3kTubbo wyoabES01o22X6j.5MJgnohmnh83_g5jV.B2a3TqqdyV0C20OmUn12du9iU2nrr1xG8qGhh7C62J _lqzw0uDc3oCBI_BuR.CYs_XVRagsbnsHfNuJN.4IoWWKSrMKjdt0JlDTDSotwzNGSWM0XhTfd_u VfK_RNuNvLhxyVmZqK_isQUDUi9rFQ7vXK8ARqCk01W0of4Afm4QjiM1iOGSJ6oVTkZxODdC73Pj ksDsK0nMFdU4XzZII1OmIC6Z1L5V59Z1A.bm5iruKAYYmZyxnbH_.o0fe78pNjOdB7QL7snWappN z_vYfV7gYodyOPohKlGK13Dztj0_tXevBFjcqnnpNi8G8wQeHMK51kF2KAyV4m00TUb9N7_fG8pe NOT3Dp7kG8_zM2XKN2c2fqrIOQ5ahUAB1yR2yRIG.6Ua3GZG1J3wnletZvlaQPAoeebxZRRXIETg 4LKNzzC8FIEE.4lay8Gxjwqc97c5Tt0gw.qQlahQegi9_TiSgi_g5UaHNnxZFjYZGPgDoXMsjXWV EVDbD3M_oE9iqPBjQB4.cC8ha5eM39drrGrPs5NmsSg2yfcV6v4Lk3oiZkhMDKNFO_Qp7Rd1QI3M ud3f5.f57PZfU7Yv9Y4uxVrOSBV9e97OeD2NJ25WQPR.dCKN9bm0S3WVU8TjvX2iapdranRI0gVp HBDmbpK359MWqnLUYTldZ2duf736IuxM_0Miexrrabr1tTx.kv9zQGjWfaA9jJg_AOh6aMSEIuC8 HCpzBaDSFG6TNgeGrOUzlO0I._1aUkb9l8.0y_Tl8JJyGYQmIQUhbIbnjK7TFs3TI2F2P7UtPEjW 7Xtp0v.5Dz8QDRQrcMebvQRbd90V01B404jO_PGVRC27Nw7Us0jrFeIQsn04YUEBDbLJt5U_E0r_ 4vjrxPTyLgDjiSC7_oVlTE59ZZP4mY8edg2lFLw2stL3LzWpCTmxHe4kMkHHQcNyKKc7fu0F4Cc1 9AA3B8RS73zDf.LwyRdNi3pCg8pcEE.iAeZ651wgijPEsK5OzIZWlkU9kUd.ZT_.iNtwvaSuiU7X ApLn27C2Kj_gLzlPbhfVyg..EyyyjtpJi9PF5oMh1usvZsG73X3GmIRqXnUtfCU9wl5rHfE_6vAy VhWUMXqP0TFWmtg5Ye95YaBv48MZxM8e.k1_RQiJPfpIp2uVcJHhy5XzPk8oLn8RRyd3mlYQxisp BcQd3lwMDU85etvveeoxwDI_WzgCBJQjgIb2pvBZERrtEtJj0z.lj3cL5oyDrJV414ZW4ukKsC9d PFyUFVOwrwGFp4HXwH5owkDk_hG5c0Y3Mwno0iW.6EUn0qTcaCdh6JZZcm3BMo8V_z15t5g0K1gH zRrvMBngIQOKSkfTLMiFMUPJUgZiGNt5MwobJUgPB2PXNSjb7qG31iUpbfc00vMCymKF4ugkI.4a YvDauT3h2VLzAKgMaHqgz5QdAvdvtivBTFvWqlrQg1o0sZcPS2517z.RggUSu2Y_qcdkpkHRjBLr o1bF9I.Owdwu34_WgAwi5m69sTu78cKxnK.m7tYihzkZP6z4Cpnx_A2ViLbobHQFq6ihH1mj8060 jnPS4W.m.gBwls05hpDaITlkmVm5RosSWi0d.sIg6_jJT.MS1i3CN6oXhv9iVCy83icpAXYRaz7t Lvgxiwy0MFrA8EZIp.sC14j2o2KHtPm9lxoE1r6lcwNInDyq95B_ur0xfJiP39w5RxGU79YQg_OZ DXNCkx19qugBLxoHYZQ_iB8CYcMWCQfNKgDjl435Kkq6QTgTp8M2pmUNN7p2eToPm8EQuZ2oYpm1 J4DArgrGLDo8E7h7s1FQmSD2J1ohQyRLqf.6dqcgkeN8OyzqKoNuBKT.Y1iapkkne.TU7g4460A. .LEnzulpQ22IXahSUwlifHP45PCkyOkeXB2__AV6U8whbRjyCuP.CD03RRqpw9fFnTeqoS0PeuTG TRnVf9WEEkMdJLNSvEgD6tpkLpVqgnC11L1c5jVYto1VNbssjhUCkTHRMas7cfuRLDD0rvyCN0cP TNKbNKMjBAtul5KMKEiQJlqITDUMElepnRSB1BsTCU5AXAM546zB9OAODZ0cFUXCT_.CJkOs2OEN s8eNY X-Sonic-MF: X-Sonic-ID: a4bd3198-c542-46ee-88eb-3680951776c9 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Tue, 6 May 2025 19:16:23 +0000 Received: by hermes--production-gq1-74d64bb7d7-fsgc5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5ce0c37b7ce67c7e36de3fce81428d44; Tue, 06 May 2025 19:16:18 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\)) Subject: Re: incremental bulds from scratch with beinstall.sh From: Mark Millard In-Reply-To: Date: Tue, 6 May 2025 12:16:07 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <86E414BD-6FA1-4B46-B0FE-DEABCED63DC5@yahoo.com> References: <28F2BDE7-5903-4C04-A570-6A407F19D5F2.ref@yahoo.com> <28F2BDE7-5903-4C04-A570-6A407F19D5F2@yahoo.com> <5BFEF4D2-0E42-46ED-899B-D27169DFC322@yahoo.com> To: Nuno Teixeira X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Rspamd-Queue-Id: 4ZsSmn4wZZz3dfv X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Spamd-Bar: ---- On May 6, 2025, at 10:47, Nuno Teixeira wrote: > I use CURRENT on my laptop and rpi4 for some time now. > I like to see changes in src tree and then rebuild world and test for = myself. > One of the things that attracts me is building and rebuilding stuff = and maybe that's why I'm so happy as a ports committer :) Ahh. Okay. This may get into how much risk of broken builds in non-obvious ways that you can tolerate. Also: How much context analysis and tracking you want to do vs. not. "man 7 build" references the likes of NO_CLEAN and NO_CLEANDIR and NO_KERNCLEAN that migth be used without use of META_MODE. That does not notice as much evdience of needing rebuild activity. NO_CLEAN If set, no object tree files are cleaned = at all. This is the default when WITH_META_MODE = is used with filemon(4) loaded. See = src.conf(5) for more details. Setting NO_CLEAN = implies NO_KERNELCLEAN, so when NO_CLEAN is set no = ker- nel objects are cleaned either. There is also: KERNFAST If set, the build target buildkernel = defaults to setting NO_KERNELCLEAN, NO_KERNELCONFIG, = and NO_KERNELOBJ. When set to a value other than = 1 then KERNCONF is set to the value of KERNFAST. and: WORLDFAST If set, the build target buildworld = defaults to setting NO_CLEAN, NO_OBJWALK, and will = skip most bootstrap phases. It will only = bootstrap li- braries and build all of userland. This = option should be used only when it is known = that none of the bootstrap needs changed and that = no new directories have been connected to the = build. These sorts of things get into your tracking context to know when to use them vs. not: more manual management. When things go wrong, they get into figuring out how to fix them --possibly involving bigger rebuilds than otherwise at that point. > The only "change" that I do in build world is: > /etc/src.conf: > WITH_MALLOC_PRODUCTION=3Dyes > WITHOUT_LLVM_ASSERTIONS=3Dyes > that might be incompatible with pkgbase since those settings are for = releases. PkgBase has both Debug and non-Debug kernels for main. It has builds of main and stable/14 as well, not just 14.* releases. Just FYI . . . PkgBase has available (for amd64 and aarch64 and . . .): main: base_latest/ and base_weekly/ Note: both Debug and non-Debug kernels are available for main. To my knowledge, PkgBase is the first form of official distribution of non-debug main kernels. (I have both types installed.) stable/14: base_latest/ and base_weekly/ releng/14.*: base_release_[3210]/ ( Also: kmods_latest_2/ kmods_quarterly_2/ with some kmods ) PkgBase has debug symbol file packages available to install and has its own /usr/src/ and /usr/src/sys/ packages (no git repo). PkgBase is (always?) based on WITH_LLVM_ASSERTIONS as far as I know. However, I'm not aware of PkgBase yet publishing anything listing with WITH_* and WITHOUT_* settings that are used for any of its builds --or other such details. I learned about assert by hitting an example failure. The status could have changed. I do not know the WITH*_MALLOC_PRODUCTION status. Do you really want/need the RPi4B to be able to build for the powerpc* and amd64 and the like? Might src.conf be used for: WITH_LLVM_TARGET_AARCH64=3D WITH_LLVM_TARGET_ARM=3D WITHOUT_LLVM_TARGET_MIPS=3D WITHOUT_LLVM_TARGET_POWERPC=3D WITHOUT_LLVM_TARGET_RISCV=3D WITHOUT_LLVM_TARGET_X86=3D Such could save some time on a RPi4B. A similar point might go for the laptop (enabling X86 instead?). WITHOUT_LLVM_TARGET_ALL=3D might be an option but it used to be there as an odd build consequence that I ran into that was tied to if the bootstrap toolchain build could be avoided vs. not. I've not retested and stuck with being explicit. Looks like there is also now: WITH*_LLVM_TARGET_BPF but it seems to be WITHOUT_LLVM_TARGET_BPF by default. WITHOUT_LLVM_TARGET_MIPS also looks to be the default for MIPS these days [on main]. Another thing you may not be interested in using is the results of WITH_CLANG_FULL: WITHOUT_CLANG_FULL Avoid building the ARCMigrate, Rewriter and StaticAnalyzer components of the Clang C/C++ compiler. Again, possibly avoiding the RPi4B spending the time building what is not used. > Cheers, >=20 > Mark Millard escreveu (ter=C3=A7a, 6/05/2025 =C3=A0(= s) 17:52): > On May 6, 2025, at 08:15, Nuno Teixeira wrote: >=20 > > Hello Mark, > >=20 > > Definitely I'm not getting the results I want with WITH_META_MODE = using BEs since most of the times I end up rebuilding almost everything = in new BE. > >=20 > > Should I stop using WITH_META_MODES a go straight to clean builds = (clean /usr/obj) instead? >=20 > If by "clean" you mean doing some form of "rm -fr" on all > or part of what is by default somewhere under /usr/ob/ : > You likely would be deleting files that would be > regenerated during a build instead of any of those being > reused. >=20 > May be I've guess wrong about what you mean by "clean > /usr/obj"? You did not comment about the above. WITH_CLEAN is an example of deleting things that might otherwise be reused instead of being built. I should have mentioned that above. > I'll note that I've never used ccache or the like: >=20 > https://man.freebsd.org/cgi/man.cgi?query=3Dccache&sektion=3D1&n=3D1 >=20 > I expect that there are others that have that might > comment about such setups. >=20 > But going in another direction: I do not know why you are > doing your own builds instead of using pre-built materials, > such as PkgBase's base_latest (updated multiple times per > day, not that you need to do updates from it that often) > or base_weekly (again, you might not update as often). >=20 > Do you have local modifications of the system source that > you are building? (That could mean not using PkgBase > materials, for example.) Just kernel updates? Just > world updates? Both? Neither? >=20 > I also do not know if you build your own packages/ports. So > I do not even known if you need a toolchain. Do you need > to do package/port builds to get security updates sooner > or some such? >=20 > Can you comment on what has to be true of your system > environment(s) for such (even if it in turn means build > times that you do not like have to be involved)? > Delimiting the tradeoff structure requirements might help > in picking a path. >=20 >=20 > A RPi4 specific note: >=20 > One core on the RPi4B executing code for which the L1 > (smallest) level cache is ineffective can saturate its > memory subsystem. Depending on details I've had > experiments in normal system build activity where using > -j3 instead of -j4 or more actually took somewhat less > time overall. (Not that the differences were huge or > anything. And they might not be systematic. But -j3 can > also help if there are also memory usage tradeoffs that > need to be managed. Does the RPi4 have 8 GiBytes of RAM? > 4 GiByte? 2 GiByte?) >=20 >=20 > A note on official PkgBase build use: >=20 > The below illustrates that it is possible to mix > official PkgBase and personal system builds in some > ways. >=20 > Not that it is on RPi4B's, but I have both PkgBase > kernels and my own kernel builds and use > /boot/loader.conf to pick which is the default > for booting. I do not boot kernels that are > older than the boot world on the media. >=20 > I boot a PkgBase world and have directory trees for > chroot or other such use with my personal world > builds, some have my personal package builds > installed and others have official package builds > installed. >=20 > I only use my personal world builds with my personal > kernel builds. (They are matched.) I never use my > personal kernel build when it is older than the > PkgBase kernel or world that I use. This means > my personal kernel build supports booting the > PkgBase based world when I use that kernel. >=20 > Overall I can investigate if any problems I run into > are reproducible without my system or package builds > involved. >=20 > I have various poudriere(-devel) jails, some use > official PkgBase based jails and others are using my > personal builds for the jail content: >=20 > # poudriere jail -l > JAILNAME VERSION OSVERSION ARCH METHOD = TIMESTAMP PATH > release-aarch64 14.2-RELEASE-p1 aarch64 pkgbase = 2025-05-05 22:11:10 /usr/local/poudriere/jails/release-aarch64 > release-armv7 14.2-RELEASE-p2 armv7 pkgbase = 2025-03-13 21:50:17 /usr/local/poudriere/jails/release-armv7 > official-aarch64 14.2-STABLE aarch64 pkgbase = 2025-05-05 22:13:47 /usr/local/poudriere/jails/official-aarch64 > official-armv7 14.2-STABLE armv7 pkgbase = 2025-03-13 21:47:04 /usr/local/poudriere/jails/official-armv7 > main-aarch64 15.0-CURRENT aarch64 pkgbase = 2025-05-05 22:15:30 /usr/local/poudriere/jails/main-aarch64 > main-CA76 15.0-CURRENT arm64.aarch64 null = 2025-02-13 01:35:39 /usr/obj/DESTDIRs/main-CA76-poud > main-CA76-bulk_a 15.0-CURRENT arm64.aarch64 null = 2025-02-13 01:35:39 /usr/obj/DESTDIRs/main-CA76-poud-bulk_a > main-CA7 15.0-CURRENT arm.armv7 null = 2025-02-20 18:16:55 /usr/obj/DESTDIRs/main-CA7-poud > main-CA7-bulk_a 15.0-CURRENT arm.armv7 null = 2025-02-20 18:16:56 /usr/obj/DESTDIRs/main-CA7-poud-bulk_a > main-armv7 15.0-CURRENT armv7 pkgbase = 2025-03-14 22:48:11 /usr/local/poudriere/jails/main-armv7 >=20 > # poudriere jail -l > JAILNAME VERSION OSVERSION ARCH METHOD TIMESTAMP = PATH > release-amd64 14.2-RELEASE-p2 amd64 pkgbase 2025-05-05 = 22:19:47 /usr/local/poudriere/jails/release-amd64 > official-amd64 14.2-STABLE amd64 pkgbase 2025-05-05 = 22:21:46 /usr/local/poudriere/jails/official-amd64 > main-ZNV4 15.0-CURRENT amd64 null 2025-02-12 = 16:03:46 /usr/obj/DESTDIRs/main-ZNV4-poud > main-ZNV4-bulk_a 15.0-CURRENT amd64 null 2025-02-12 = 16:03:46 /usr/obj/DESTDIRs/main-ZNV4-poud-bulk_a > main-ZNV4-dbg 15.0-CURRENT amd64 null 2025-04-02 = 09:20:08 /usr/obj/DESTDIRs/main-ZNV4-poud-dbg > main-amd64 15.0-CURRENT amd64 pkgbase 2025-05-05 = 22:26:12 /usr/local/poudriere/jails/main-amd64 >=20 > (I've never bothered with i386 in amd64 contexts and > have never used FreeBSD on an actual i386 class system.) >=20 > > My first concern is to speed up builds expecially on rpi4. >=20 > Per some prior questions: What other constraints must > also be met? >=20 > > Any hints are welcome. > >=20 > > Thanks, > >=20 > >=20 > > Mark Millard escreveu (segunda, 5/05/2025 =C3=A0(s= ) 23:18): > >> Nuno Teixeira wrote on > >> Date: Mon, 05 May 2025 20:37:09 UTC : > >>=20 > >> > (...) > >> >=20 > >> > Don't forget to `env NO_PKG_UPGRADE=3Dyes beinstall.sh` to not = mess with > >> > ports and stuff. > >> >=20 > >> > Nuno Teixeira escreveu (segunda, 5/05/2025 = =C3=A0(s) > >> > 21:34): > >> >=20 > >> > > Hello, > >> > > > >> > > Using incremental WITH_META_MODE builds, after installation = with > >> > > beinstall.sh, building same src, a complete compilation = happens. > >> > > > >> > > If someone uses this script, could you please do the following = test: > >> > > > >> > > WITH_META_MODE=3Dyes (/etc/src-env.conf) > >> > > filemon module loaded > >> > > > >> > > # cd /usr/src > >> > > # make buildworld-jobs buildkernel-jobs > >>=20 > >> The above used older commands and files from before > >> the following install. META_MODE recorded the use of > >> those commands. > >>=20 > >> Example .meta mode file content: > >>=20 > >> # Meta data file = /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/lib/libc++/li= bc++.a.meta > >> CMD @echo building static c++ library > >> CMD @rm -f libc++.a > >> CMD ar -crsD libc++.a algorithm.o any.o atomic.o barrier.o bind.o = charconv.o chrono.o condition_variable.o condition_variable_destructor.o = debug.o exception.o filesystem/directory_iterator.o filesyste > >> m/int128_builtins.o filesystem/operations.o functional.o future.o = hash.o ios.o iostream.o locale.o memory.o mutex.o mutex_destructor.o = new.o optional.o random.o random_shuffle.o regex.o shared_mutex.o > >> stdexcept.o string.o strstream.o system_error.o thread.o typeinfo.o = utility.o valarray.o variant.o vector.o cxxrt_auxhelper.o = cxxrt_dynamic_cast.o cxxrt_exception.o cxxrt_guard.o = cxxrt_libelftc_dem_g > >> nu3.o cxxrt_memory.o cxxrt_stdexcept.o cxxrt_terminate.o = cxxrt_typeinfo.o > >> CWD = /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/lib/libc++ > >> TARGET libc++.a > >> -- command output -- > >> building static c++ library > >>=20 > >> -- filemon acquired metadata -- > >> # filemon version 5 > >> # Target pid 22471 > >> # Start 1611359217.214996 > >> V 5 > >> E 22961 /bin/sh > >> R 22961 /etc/libmap.conf > >> R 22961 /var/run/ld-elf.so.hints > >> R 22961 /lib/libedit.so.7 > >> R 22961 /lib/libc.so.7 > >> R 22961 /lib/libncursesw.so.9 > >> R 22961 /usr/share/locale/C.UTF-8/LC_CTYPE > >> F 22961 22962 > >> E 22962 = /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/us= r/sbin/rm > >> R 22962 /etc/libmap.conf > >> R 22962 /var/run/ld-elf.so.hints > >> R 22962 /lib/libc.so.7 > >> R 22962 /usr/share/locale/C.UTF-8/LC_CTYPE > >> D 22962 libc++.a > >> X 22962 0 0 > >> . . . > >>=20 > >> So META_MODE has lots of files that were used > >> that it can later detect being newer than the > >> prior build results, leading to rebuilds based > >> on those newer files. > >>=20 > >> > > # ./tools/build/beinstall.sh > >>=20 > >> The new be will have various updated files > >> that could be different by content and, for > >> commands, could behave differently than those > >> used to do the prior build. Detecting newer > >> time stamps on such used files leads to > >> rebuild activity. > >>=20 > >> More than /usr/src/ and /usr/obj/ content > >> are involved as well. > >>=20 > >> Note that the new be is based on somewhat > >> different files than the original > >> buildworld-jobs buildkernel-jobs was based > >> on. > >>=20 > >> > > # reboot > >> > > > >>=20 > >> (I presume booting into the new be here.) > >>=20 > >> > > # cd /usr/src > >> > > # make buildworld-jobs buildkernel-jobs > >>=20 > >> META_MODE will notice when commands are used > >> that are newer than when the prior build was > >> done. Similarly for other files that may be > >> read. It will make sure that the newer commands > >> and files are allowed to produce new results > >> that potentially could be distinct in content > >> from what the old context produced for results. > >>=20 > >> > > > >> > > Since src and obj are the same from one BE to newer BE, minimal > >> > > compilation should happen, not a full one. > >>=20 > >> META_MODE is more careful than that. > >>=20 > >> Note: I'm not claiming that new behavior that is > >> needed is likely for lots of the files with new > >> dates. But META_MODE is biased to avoiding leaving > >> in place something that should have been updated. > >>=20 > >> > > > >> > > Am I missing something here? > >> > > > >>=20 > >> Note that make has a -dM option: > >>=20 > >> M Print debugging information about =E2=80=9Cmeta=E2= =80=9D mode decisions > >> about targets. > >>=20 > >> So, for example, > >>=20 > >> file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/awk' is newer than the target... > >> file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/cap_mkdb' is newer than the target... > >> file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/cat' is newer than the target... > >> file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/cp' is newer than the target... > >> file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/crunchgen' is newer than the target... > >> file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/crunchide' is newer than the target... > >> file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/dd' is newer than the target... > >> . . . > >>=20 > >> Various . . ./tmp/legacy/. . ./*bin/ actually were > >> links to files. > >>=20 > >> Ultimately buildworld then installworld lead to new > >> dates for a bunch of files used. Later use of > >> META_MODE notices such and rebuilds based on the > >> newer files. (It is a lot of detail to go through > >> it all.) > >>=20 > >> Back in 2021 and 2023 I got help with exploring > >> avoiding lots of these. But, in the end, it > >> involved use of experimental code in > >> share/mk/src.sys.obj.mk to provide a new > >> definition to use to build some paths with. > >>=20 > >> The experiments were an unsupported activity that > >> produced an unsupported change to allow > >> configurable enabling of taking risks with not > >> updating files that possibly should be updated. > >>=20 > > =3D=3D=3D Mark Millard marklmi at yahoo.com