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