Date: Sun, 28 Jan 2024 14:34:21 -0800 From: Mark Millard <marklmi@yahoo.com> To: david@catwhisker.org Cc: FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org> Subject: Re: Should changes in src/usr.sbin/bhyve/ trigger an llvm rebuild? Message-ID: <B1231700-D7A1-4190-AA2A-495CEA954535@yahoo.com> In-Reply-To: <ZbbPyYNtF6prkdtd@albert.catwhisker.org> References: <EAD76C2C-065E-4EFA-901F-1C0FD13FFC65.ref@yahoo.com> <EAD76C2C-065E-4EFA-901F-1C0FD13FFC65@yahoo.com> <ZbZ2u9FlUhvb1orU@albert.catwhisker.org> <5BCB8F1A-B5D5-4506-87E1-8B26E713C6F5@yahoo.com> <ZbbPyYNtF6prkdtd@albert.catwhisker.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[Note: your email is rejecting my E-mail: 554: 5.7.1 ] On Jan 28, 2024, at 14:06, David Wolfskill <david@catwhisker.org> wrote: > On Sun, Jan 28, 2024 at 10:20:30AM -0800, Mark Millard wrote: >> ... >>> That said, one of the machines in question is my local "build = machine" -- >>> and for it, in addition to in-place source updates, I also do = (weekly) >>> updates of my "production" machines (at home). >>>=20 >>> And for that case, the production machines mount the builder's = /usr/src >>> and /usr/obj (via NFS) read-only. >>=20 >> Which machine(s) are doing the llvm rebuild that >> you were hoping would not happen? >=20 > Each of the 3 machines that I update via in-place source updates: the > above-cited "buildl machine" and a couple of laptops. >=20 >> What was the context like for the history on that machine? >=20 > Each of the machines is updated daily (except when I'm away and > off-Net); each is updated to the same commit (as each has a local > private mirror for the FreeBSD git repositories, and after updating = the > build machine's mirror, I use rsync to ensure that the laptops' = mirrors > are in sync with that). >=20 > Update histories for the build machine and one of the laptops is > available at https://www.catwhisker.org/~david/FreeBSD/history/ >=20 > In each of the 3 cases this morning, the machine was running > stable/14-n266551-63a7e799b32c and updated to > stable/14-n266554-2ee407b6068a, which (as noted earlier) only changed > src/usr.sbin/bhyve/pci_nvme.c. And each machine rebuilt llvm durng > "make buildworld". When you built and then installed stable/14-n266551-63a7e799b32c if you had then simply started another build where you installed, it would have rebuilt llvm at that point --before=20 stable/14-n266554-2ee407b6068a updated source was even present. The install of 63a7e799b32c made various tools used to do builds newer than the files used to do the build of 63a7e799b32c. That is enough for META_MODE to initiate rebuild activity so that things end up synchronized to be based on the updated installed tools. (Some tools might not be updated, others might be. The details depend on which are updated with new timestamps used by makes "newer" checks.) Try running make with the debug mode turned on that reports the "newer than" notices for what leads to rebuild activity (make -dM) after a notable installworld but before any source code updates. You might not like the full range of things checked but you will see why things are rebuilt. META_MODE tests date relationships among more files than you are considering. >=20 >> (The below had to be written without understanding >> of such things.) >>=20 >> Here is an example META_MODE line recording a >> tool used during a particular file's rebuild: >>=20 >> E 22961 /bin/sh >>=20 >> So installing an update to /bin/sh via isntallworld >> would lead to the later META_MODE (re)build >> indicating that the file needs to be rebuilt, just >> because /bin/sh ends up being newer after the >> installworld . >=20 > Perhaps I should rephrase my query to "*Should* an update of (only) > src/usr.sbin/bhyve/pci_nvme.c cause 'make buildworld' using META_MODE = to > rebuild llvm?" I seem to have empirical evidence that it does do = that. Changes to src/usr.sbin/bhyve/pci_nvme.c are not a cause of the rebuild. The prior installworld of 63a7e799b32c is the cause of the rebuild. If you had tried the build before updating the source tree, it still would have rebuilt llvm. >=20 >> There are other examples of recorded paths to tools >> in .meta file, such as (my old context example >> used in an old E-mail exchange): >>=20 >> = /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/us= r/sbin/awk >>=20 >> So if /usr/obj/. . ./tmp/legacy/usr/sbin/awk is newer than the file >> potentially being rebuilt, make ends up with: >> .... >=20 > Right; after some discussion with Simon and/or Bryan (back on 08 July > 2017), I augmented /etc/src.conf on the laptops to include: >=20 > .MAKE.META.IGNORE_PATHS +=3D /usr/local/etc/libmap.d >=20 > because I (also) had: >=20 > PORTS_MODULES+=3Dx11/nvidia-driver-390 >=20 > in there, so x11/nvidia-driver-390 was being rebuilt every time the > kernel was being rebuilt, and that caused /usr/local/etc/libmap.d to > get an update. So META_MODE wasn't cutting down on the rebuilds in = that > case. >=20 > The above .MAKE.META.IGNORE_PATHS line helped address that issue. >=20 > Perhaps something somewhat similar is wanted to prevent the situation > that catalyzed the initial message in this thread? =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B1231700-D7A1-4190-AA2A-495CEA954535>