Date: Thu, 23 Feb 2023 17:42:19 -0800 From: "Simon J. Gerraty" <sjg@juniper.net> To: Mark Millard <marklmi@yahoo.com> Cc: Bryan Drewery <bdrewery@FreeBSD.org>, Current FreeBSD <freebsd-current@FreeBSD.org>, Peter <pmc@citylink.dinoex.sub.org>, <sjg@juniper.net> Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) Message-ID: <93460.1677202939@kaos.jnpr.net> In-Reply-To: <1B5FCF8A-0DFD-4246-8464-65A44A40529F@yahoo.com> References: <B74790D9-FBC2-4818-BEAF-34E5B705C460@yahoo.com> <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <DB0C7B41-2101-4C5C-BFC8-3C95CC0B9F6F@yahoo.com> <73088.1611797582@kaos.jnpr.net> <CB7040D0-3BF4-496F-A54F-87E5378016E0@yahoo.com> <F6BF110D-7855-4A10-A53F-52B34282234F@yahoo.com> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> <29887.1677115125@kaos.jnpr.net> <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> <7FB6F619-6E71-4075-8A6C-573564371DD5@yahoo.com> <2655.1677134606@kaos.jnpr.net> <242BB478-B2FE-4BCC-A56E-098F3FEB3EE1@yahoo.com> <42586.1677183334@kaos.jnpr.net> <AE95CF5D-0B7E-4DA3-8777-5FA47E1751D8@yahoo.com> <30.1677189836@kaos.jnpr.net> <1B5FCF8A-0DFD-4246-8464-65A44A40529F@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mark Millard <marklmi@yahoo.com> wrote:
> Simplifying context . . .
> . . .
> > As I mentioned previously, there is no variablity of OBJTOP within the
> > context of a single make instance - at least not once it starts runnin=
g
> > targets.
> >
> >> . . .
> >
> > .MAKE.META.IGNORE_PATHS +=3D ${OBJTOP}/tmp/legacy/usr
> =
> I'll use that definition line for the below.
Ok.
> > should result in nothing under ${OBJTOP}/tmp/legacy/usr causing a targ=
et
> > to be out of date - just because it is newer.
> =
> I'll ignore there that that is skipping too much
> and just show what happens for the 2nd buildkernel
> of 2 in a row when I use that exact line for both
> make runs.
> =
> First counts of the "is newer than" lines, counting
> separate program names separately:
> =
> # cat /usr/obj/BUILDs/main-amd64-nodbg-clang/sys-typescripts/typescript-=
make-amd64-nodbg-clang-amd64-host-2023-02-23:16:15:18 | grep "is newer tha=
n the target" | sed -
> e "s@^.*: file '@file '@" | sort | uniq -c | sort -rn | more
> 2553 file '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd=
64/tmp/legacy/usr/sbin/realpath' is newer than the target...
> 1001 file '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd=
64/tmp/legacy/usr/sbin/ln' is newer than the target...
> =
It is of course critical to know what OBJDIR is at this point.
also can you show me the line in the meta file that is matching.
If you add the .info line I suggested in kern.mk or kmod.mk
you should get some useful info.
> Thousands of rebuilt things based on:
> =
> . . ./tmp/legacy/usr/sbin/realpath
> . . ./tmp/legacy/usr/sbin/ln
> =
> It appears that buildkernel does not use an OBJTOP definition
> that references:
It is possible it does not have a "normal" value for it.
Kernel builds start in the objdir so .CURDIR is actually under
OBJTOP, so unless the makefiles have appropriate logic for that case,
and depending on how OBJTOP is derrived, you may have a bogus value.
The fix in that case would be the makefile setting OBJTOP.
> =
> /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64
> =
> in my context.
> =
> For reference of Build lines paired with a few of those "is newer
> than" lines:
> =
> =
> I've still no clue of a notation that avoids this for
> my choice to use personal MAKEOBJDIRPREFIX paths:
That should work, looking at share/mk/src.sys.obj.mk
though looks like you might get
OBJROOT?=3D ${_default_makeobjdirprefix}${SRCTOP}/
which may not be valid for a kernel build.
At least ${.OBJDIR} will not have that ${OBJROOT} as a prefix
and some of the settings for OBJTOP look just wrong to me:
OBJTOP:=3D ${OBJROOT:H}
is the opposite of what the relationship b/w OBJROOT and OBJTOP are in
DIRDEPS_BUILD but it looks like
OBJTOP:=3D ${OBJROOT}${MACHINE}.${MACHINE_ARCH}
is more likely to be used, but given the above default for OBJROOT
that is unlikely to work for a kernel build.
Looks like share/mk/src.sys.obj.mk grok's SB (the setup I/we use) so you
can take control by setting SB and SB_OBJROOT to anything you like and
it should be used for OBJROOT and presumably hence OBJTOP even for a
kernel build. Though I normally use MAKEOBJDIR (similar to the way it
is set in _default_makeobjdir), I don't know how well that works with
legacy targets though - there's a lot of baked in assumptions about
using MAKEOBJDIRPREFIX.
Again that .info line I gave you would provide some useful clues.
--sjg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?93460.1677202939>