Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes)
- Reply: Simon J. Gerraty: "Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes)"
- In reply to: Mark Millard : "Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes)"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 22 Feb 2023 23:19:41 UTC
[Added a question about a possible typo in the old original message.] On Feb 21, 2023, at 13:31, Mark Millard <marklmi@yahoo.com> wrote: > [This will be a question relative to the old material below.] > > On Jan 27, 2021, at 17:33, Simon J. Gerraty <sjg@juniper.net> wrote: > >> Mark Millard via freebsd-current <freebsd-current@FreeBSD.org> wrote: >>>>> Given an already built, installed and booted system version, I've >>>>> noted a big difference for META_MODE in 2 rebuild contexts (no >>>>> source updates involved): >>>>> >>>>> *) Prior buildworld buildkernel, installkernel, installworld, boot >>>>> presumed before (A) and before (B) below. >> >> Yes installworld is going to cause problems unless you tell meta mode to >> ignore everything outside of the src/obj tree. >> But even that isn't enough as you note below. >> >>>>> So I used make -dM for the commented buildworld buildkernel lines, logging >>>>> the build output and later diff'ing them. >>>>> >>>>> Result that I noticed? Lots of lines uniquely from (B)'s case, ending with >>>>> one of: >>>>> >>>>> file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/awk' is newer than the target... >> >> Yes. That would be expected. >> I think Bryan added some knobs to mitigate some of this. >> >> grep -n META.*IGNORE share/mk/*mk >> >> might be instructive. >> >>>>> Many/most/all(?) of these seem to me to be unlikely to actually need to >>>>> contribute to what needs to be rebuilt (just based on being newer). So >>>>> the option to ignore (some of?) them could be useful in making META_MODE >>>>> builds quicker. >> >> Yes on all counts. That's why bmake provides a number of knobs to >> ignore such things. >> They are listed in the man page in increasing order of expense. >> >> One of the risks of the sort of introspection meta mode does, is delving >> too deep (like the dwarfs ;-) >> >> The .MAKE.META.IGNORE_* and .MAKE.META.BAILIWICK variables help to >> contain the potential insanity. >> >>>> The following from one of the .meta files makes the point that rm use >>>> in the example is unlikely to be important to needing to rebuild, >>>> despite it actually causing a file rebuild. Nor is the specific echo >>>> command listed relevant. Only the "ar" command is: >>>> >>>> # Meta data file /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/lib/libc++/libc++.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 >> >>>> -- 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/usr/sbin/rm >> >>>> The timestamp on . . ./tmp/legacy/usr/sbin/rm is not >>>> actually relevant to if libc++.a needs to be rebuilt. >> >> True. >> If there is nothing under .../tmp/legacy that should be counted you can >> just: >> >> .MAKE.META_IGNORE_PATHS += that path Was that supposed to be ("." vs. "_"): .MAKE.META.IGNORE_PATHS += that path The later ones listed have ".". >> which would be the cheapest option. >> >> If however there are things that should be considered you'd have to >> use a much more specific list of .MAKE.META_IGNORE_PATHS or (Same question applies to the above.) >> perhaps something like: >> >> .MAKE.META.IGNORE_PATTERNS += */rm >> >> would ignore an rm binary regardless of where found. >> >> worst case you might need something like: >> >> # realpath >> .MAKE.META.IGNORE_FILTER += tA >> # ignore anything here >> .MAKE.META.IGNORE_FILTER += N*/tmp/legacy/usr/bin/* >> >> Unlike .MAKE.META.IGNORE_PATTERNS which is a list of patterns to match >> the goal with .MAKE.META.IGNORE_FILTER is to reduced to an empty string >> paths to be ignored. >> >>>> Of course, the structure also point out the judgment >>>> is specific to understanding the sequence of CMD's >>>> listed above. Only a hack of ignoring, not recording, >>>> or commenting out the filemon lines ending in >>>> /tmp/legacy/usr/sbin/rm would seem to avoid the @rm >>>> handling issue. Such might well have its own risks. >> >> No hacking needed, there are a range of knobs to help. >> >>> Just for reference for more about the sequencing involved: >>> >>> Looks like in my example various . . ./tmp/legacy/. . ./*bin/ >>> actually are links to files in: >>> >>> /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/bin/ >>> >>> and the later after-install buildworld "Rebuilding the >>> temporary build tree" step leads to the updated dates for >>> files in that area, updated via the code that reports: >>> >>> Linking host tools into /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/bin >>> >>> So the prior installworld leaves updated dates and the >>> linking to those installed files makes >>> . . ./tmp/legacy/. . ./*bin/* have the newer dates show >>> up for the legacy paths as well. >>> >>> In turn the dependency tracking via META_MODE uses the new >>> dates on . . ./tmp/legacy/. . ./*bin/* files to cause >>> rebuilds of more materials than if installworld had not >>> been done. >>> >>> It is not obvious if Bryan D. would find the effort to avoid >>> this worthwhile for the contexts that drive FreeBSD's build >>> environment choices. >> >> For people that use installworld and also want META_MODE >> it would seem some additional IGNORE work may be beneficial. > > Since some of the paths reported ended up being links > (symbolic, as I remember), what are the principles for > which form of paths should be the basis for paths in > the likes of: > > .MAKE.META_IGNORE_PATHS (The above may be a typo relative to .MAKE.META.IGNORE_PATHS .) > .MAKE.META.IGNORE_PATTERNS > .MAKE.META.IGNORE_FILTER > > Target of link? Path to the link itself, not the > target? Both? > > (Something had interrupted my explorations back then and > I'd forgotten about your note and have never done the > exploration. Trying to partially answer a question on the > lists lead to me reviewing the old thread and running into > your note again.) > === Mark Millard marklmi at yahoo.com