Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes)

From: Simon J. Gerraty <sjg_at_juniper.net>
Date: Thu, 23 Feb 2023 06:23:49 UTC
Mark Millard <marklmi@yahoo.com> wrote:
> >
> > Is there anything under ${OBJTOP}/tmp that you don't want to ignore?
> 
> More than just _bootstrap_tools_links entries end up in
> ${WORLDTMP}/legacy/bin/  (so in ${WORLDTMP}/legacy/sbin/
> via the symbolic link pointing to ${WORLDTMP}/legacy/bin/ ).
> So: yes.
> 
> Also, OBJTOP is not constant over all the parts of
> buildworld buildkernel . Having the late-substitution
> form of notation ${OBJTOP} might not be appropriate
> for the content of .MAKE.META.IGNORE_PATHS .

Fwiw .MAKE.META.IGNORE_PATHS is evaluated when meta_init() is
called after all the makefiles have been read - and had a
chance to influence .MAKE.MODE, so I'm not sure how varaiablity of
OBJTOP would matter?

> > .MAKE.META.IGNORE_PATHS+= ${OBJTOP}/tmp/
> 
> (Ignoring the variability of OBJTOP issue . . .)
> 
> I do not expect that would work: ignoring things
> it likely should not.

Sure, but it may be useful as an experiment to ensure things are
behaving as expected.

> Also, I'd rather grow a smaller set of ignores
> gradually to make it easier to detect if an
> addition starts causing a problem and can be
> backed out. Starting with everything ignored
> would make things much harder to figure out
> when ignoring creates a problem.

Yes.

> 
> > You might need ${OBJTOP:tA}/tmp/
> > or both.

I found it necessary in the unit tests to add :tA to both TMPDIR
and .OBJDIR to get sane result on one test platform.

> >> It is using paths that match the -dM output lines ( sbin
> >> use despite sbin -> ../bin being a symbolic link).

use :tA if you want to ensure consistent results.

> > I really need to add some unit-tests for these...

Done - not yet imported to FreeBSD though

> You may want to wait while I see if I can come up with
> a better example context to show things. I only just
> noticed the late-substitution potential issue and
> started looking for a way to avoid it, for example.
> (Either a value that does not vary or a form of
> causing up-front substitutions in my make.conf .)

Ok