Re: 13.2 BETA2: how do debug META_MODE?

On Feb 21, 2023, at 18:10, Peter <pmc@citylink.dinoex.sub.org> wrote:

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

Intersting.

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

The implication is that "install -C" is in use, quoting the
man page:

     -C      Copy the file.  If the target file already exists and the files
             are the same, then do not change the modification time of the
             target.  If the target's file flags and mode need not to be
             changed, the target's inode change time is also unchanged.

     -c      Copy the file.  This is actually the default.  The -c option is
             only included for backwards compatibility.

-C might have more of an effect in a reproducible-build
style build process than on a non-reproducible-build
style one.


===
Mark Millard
marklmi at yahoo.com