Re: 13.2 BETA2: how do debug META_MODE?
- Reply: Mark Millard : "Re: 13.2 BETA2: how do debug META_MODE?"
- In reply to: Mark Millard : "Re: 13.2 BETA2: how do debug META_MODE?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 22 Feb 2023 02:10:43 UTC
On Tue, Feb 21, 2023 at 11:56:13AM -0800, Mark Millard wrote: ! On Feb 21, 2023, at 04:55, Peter <pmc@citylink.dinoex.sub.org> wrote: ! ! > ! # cd /usr/src/ ! > ! # env WITH_META_MODE=yes make buildworld ! > ! # env WITH_META_MODE=yes make installworld ! > ! # env WITH_META_MODE=yes make buildworld (again #0) ! > ! ## no more rebuilds below? ! > ! # env WITH_META_MODE=yes make buildworld (again #1) ! > ! # env WITH_META_MODE=yes make buildworld (again #2) ! > ! > But what is the difference between #0 and #1? ! ! awk, cp, ln, rm, sed, and many more from ! . . ./tmp/legacy/usr/sbin/have new dates ! for rebuilds after installworld (that targets ! the running system). Not true for #1 and #2. ! ! The dates on these tools being more recent than ! the files that they were involved in producing ! leads to rebuilding those files. That in turn ! leads to other files being rebuilt. ! ! make with -dM reports the likes of: ! ! file '. . ./tmp/legacy/usr/sbin/awk' is newer than the target... ! ! explicitly as it goes. As I remember tmp/legacy/usr/sbin/ ! was always part of the path for what I found. Mark, thanks a lot for the proper input at the right time! This put me on the right track and I mananged to analyze and understand what is actually happening. It looks like my issue does resolve itself somehow, and things start to behave as expected again after four builds. ! I did not do the analysis of how (e.g.) tmp/legacy/usr/sbin/awk ! ended up being newer than such a target and, so, causing a ! rebuild of that target. I was going the direction: that ! it is newer really is unlikely to justify the rebuild for ! the target(s) in question. The other direction about how ! it got to be newer is also relevant. I have now analyzed some parts of it. META_MODE typically finds some build-tools to rebuild, but then if the result is not different from what was there before, then "install" will not copy it to the bin-dir, and so the avalanche gets usually avoided.