Skip site navigation (1)Skip section navigation (2)
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>

next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 23, 2023, at 19:54, Simon J. Gerraty <sjg@juniper.net> wrote:
>=20
>>=20
>> 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):
>>=20
>> make[4]: "/usr/main-src/sys/conf/kmod.mk" line 72:
>> .CURDIR=3D/usr/main-src/sys/modules/aac
>> =
.OBJDIR=3D/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/=
sys/GENERIC-NODBG/modules/usr/main-src/sys/modules/aac
>> =
OBJTOP=3D/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/s=
ys/GENERIC-NODBG/modules/usr/main-src
>=20
> 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
>=20
> you really want it fixed at
>=20
> /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64
>=20
> which is difficult given the way it is defined in
> src.sys.obj.mk

Yep, but possibly understated.

> Perhaps you want to be using
>=20
> .MAKE.META.IGNORE_PATHS+=3D ${MAKEOBJDIRPREFIX}/tmp/legacy/usr
> or is that ${MAKEOBJDIRPREFIX}/${TARGET}.${TARGET_ARCH}/tmp/legacy/usr=20=

>=20

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 +=3D ${MAKEOBJDIRPREFIX}/tmp/legacy/usr
. . .

make[4]: "/usr/main-src/sys/conf/kmod.mk" line 72:=20
.CURDIR=3D/usr/main-src/sys/modules/aac
=
.OBJDIR=3D/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/=
sys/GENERIC-NODBG/modules/usr/main-src/sys/modules/aac
=
OBJTOP=3D/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/s=
ys/GENERIC-NODBG/modules/usr/main-src
.MAKE.META.IGNORE_PATHS=3D/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/GENERI=
C-NODBG/modules/tmp/legacy/usr
make[4]: "/usr/main-src/sys/conf/kern.mk" line 3:  =
.CURDIR=3D/usr/main-src/sys/modules/aac
=
.OBJDIR=3D/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/=
sys/GENERIC-NODBG/modules/usr/main-src/sys/modules/aac
=
OBJTOP=3D/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/s=
ys/GENERIC-NODBG/modules/usr/main-src
.MAKE.META.IGNORE_PATHS=3D/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/GENERI=
C-NODBG/modules/tmp/legacy/usr
=
/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI=
C-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/legac=
y/usr/sbin/realpath' is newer than the target...
Building =
/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI=
C-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/GENERI=
C-NODBG/modules

But looking outside the "modules" part of the kernel build
log ends up showing:

.MAKE.META.IGNORE_PATHS=3D/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/GENERI=
C-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).

=3D=3D=3D
Mark Millard
marklmi at yahoo.com




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?21F1E7D4-D709-4DFF-98D6-51795B9BB291>