Re: Should changes in src/usr.sbin/bhyve/ trigger an llvm rebuild?

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).
> > 
> > And for that case, the production machines mount the builder's /usr/src
> > and /usr/obj (via NFS) read-only.
> 
> Which machine(s) are doing the llvm rebuild that
> you were hoping would not happen?

Each of the 3 machines that I update via in-place source updates: the
above-cited "buildl machine" and a couple of laptops.

>What was the context like for the history on that machine?

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).

Update histories for the build machine and one of the laptops is
available at https://www.catwhisker.org/~david/FreeBSD/history/

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".

> (The below had to be written without understanding
> of such things.)
> 
> Here is an example META_MODE line recording a
> tool used during a particular file's rebuild:
> 
> E 22961 /bin/sh
> 
> 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 .

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.

> 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):
> 
> /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/awk
> 
> So if /usr/obj/. . ./tmp/legacy/usr/sbin/awk is newer than the file
> potentially being rebuilt, make ends up with:
> ....

Right; after some discussion with Simon and/or Bryan (back on 08 July
2017), I augmented /etc/src.conf on the laptops to include:

.MAKE.META.IGNORE_PATHS += /usr/local/etc/libmap.d

because I (also) had:

PORTS_MODULES+=x11/nvidia-driver-390

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.

The above .MAKE.META.IGNORE_PATHS line helped address that issue.

Perhaps something somewhat similar is wanted to prevent the situation
that catalyzed the initial message in this thread?

Peace,
david
-- 
David H. Wolfskill                              david@catwhisker.org
Do these ends really justify those means?

See https://www.catwhisker.org/~david/publickey.gpg for my public key.