Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes)
- Reply: Mark Millard : "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: 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