Date: Thu, 23 Feb 2023 20:57:20 -0800 From: Mark Millard <marklmi@yahoo.com> To: "Simon J. Gerraty" <sjg@juniper.net> Cc: Bryan Drewery <bdrewery@FreeBSD.org>, Current FreeBSD <freebsd-current@FreeBSD.org>, Peter <pmc@citylink.dinoex.sub.org> Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) Message-ID: <21F1E7D4-D709-4DFF-98D6-51795B9BB291@yahoo.com> In-Reply-To: <17672.1677210880@kaos.jnpr.net> 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> <93460.1677202939@kaos.jnpr.net> <F02F01EE-9866-4F37-884B-74A2665A5F08@yahoo.com> <17672.1677210880@kaos.jnpr.net>
index | next in thread | previous in thread | raw e-mail
On Feb 23, 2023, at 19:54, Simon J. Gerraty <sjg@juniper.net> wrote:
>
>>
>> First some output log lines around a few sbin/realpath "is newer than"
>> related Building lines, with the .info lines in place now (I've
>> got both kmod.mk and kern.mk with the .info line, likely producing
>> redundant output but I did not know up front for sure):
>>
>> make[4]: "/usr/main-src/sys/conf/kmod.mk" line 72:
>> .CURDIR=/usr/main-src/sys/modules/aac
>> .OBJDIR=/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG/modules/usr/main-src/sys/modules/aac
>> OBJTOP=/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG/modules/usr/main-src
>
> So as you can see that OBJTOP not does provide a match for where
> /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/usr/sbin/realpath is
>
> you really want it fixed at
>
> /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64
>
> which is difficult given the way it is defined in
> src.sys.obj.mk
Yep, but possibly understated.
> Perhaps you want to be using
>
> .MAKE.META.IGNORE_PATHS+= ${MAKEOBJDIRPREFIX}/tmp/legacy/usr
> or is that ${MAKEOBJDIRPREFIX}/${TARGET}.${TARGET_ARCH}/tmp/legacy/usr
>
I had started with trying to use MAKEOBJDIRPREFIX but it
appeared to end up with an empty expansion in something
I'd looked at, making the addition to
.MAKE.META.IGNORE_PATHS ineffective.
But with the .info lines in place, I should probably
recheck an example with ${MAKEOBJDIRPREFIX} in it.
(Expecting .MAKE.META.IGNORE_PATHS to not work but
showing what happens for the MAKEOBJDIRPREFIX use.)
This turns out to be different for "modules" vs.
"pure kernel". I start with a "modules" example
below.
So for .MAKE.META.IGNORE_PATHS += ${MAKEOBJDIRPREFIX}/tmp/legacy/usr
. . .
make[4]: "/usr/main-src/sys/conf/kmod.mk" line 72:
.CURDIR=/usr/main-src/sys/modules/aac
.OBJDIR=/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG/modules/usr/main-src/sys/modules/aac
OBJTOP=/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG/modules/usr/main-src
.MAKE.META.IGNORE_PATHS=/bin/sh /bin /lib /rescue /sbin /usr/bin /usr/lib /usr/sbin /usr/share /usr/include /usr/local/etc/libmap.d /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG/modules/tmp/legacy/usr
make[4]: "/usr/main-src/sys/conf/kern.mk" line 3: .CURDIR=/usr/main-src/sys/modules/aac
.OBJDIR=/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG/modules/usr/main-src/sys/modules/aac
OBJTOP=/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG/modules/usr/main-src
.MAKE.META.IGNORE_PATHS=/bin/sh /bin /lib /rescue /sbin /usr/bin /usr/lib /usr/sbin /usr/share /usr/include /usr/local/etc/libmap.d /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG/modules/tmp/legacy/usr
/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG/modules/usr/main-src/sys/modules/aac/machine.meta: 23: file '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/usr/sbin/realpath' is newer than the target...
Building /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG/modules/usr/main-src/sys/modules/aac/machine
So, it looks like it ended up with MAKEOBJDIRPREFIX being:
/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG/modules
But looking outside the "modules" part of the kernel build
log ends up showing:
.MAKE.META.IGNORE_PATHS=/bin/sh /bin /lib /rescue /sbin /usr/bin /usr/lib /usr/sbin /usr/share /usr/include /usr/local/etc/libmap.d /tmp/legacy/usr
So MAKEOBJDIRPREFIX expanded to empty, resulting in:
/tmp/legacy/usr .
So: more can-not-get-there-from-here. I've still no
clue of a notation that will work. (It would need to
apply to buildworld as well, making for more
constraints than just working for buildkernel.)
As for:
${MAKEOBJDIRPREFIX}/${TARGET}.${TARGET_ARCH}/tmp/legacy/usr
my memory is that ${TARGET}.${TARGET_ARCH} are supposed to
only be use in the top level makefiles. But, just seeing
what results . . .
/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG/modules/amd64.amd64/tmp/legacy/usr
Still not right for "modules".
I'll note that outside modules, it is:
/amd64.amd64/tmp/legacy/usr
and still not right (MAKEOBJDIRPREFIX expanded
to empty).
I still do not know notation to make .MAKE.META.IGNORE_PATHS
effective for the specific list of tmp/legacy/usr/sbin/*
examples in question.
Effectively, it appears that the coverage of
.MAKE.META.IGNORE_PATHS is just incomplete (via the
notational constraints it is used within).
===
Mark Millard
marklmi at yahoo.com
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?21F1E7D4-D709-4DFF-98D6-51795B9BB291>